Associating artifact with a Work Item in another Project
I am testing a project with multiple subsystems. Each subsystem has its own RTC project and I have a separate project for my Test artifacts. My Test project includes various documents as well as integration tests and my own tests for the subsystems. (Each subsystem team is expected to have their own Unit tests included in their project.)
I have shared my Test project with the developers, and they can load Eclipse projects within it to get at the various parts that are of interest to them. When I find a bug, I want to be able to share code or other artifacts from my Test project by changing the status on one of the Developers Work Items, putting notes in the Discussion of that Work Item, and then including a link to the artifact in my Test project.
Is there a good way to link to my artifacts? I've tried going in to the Links for the Work Item and Adding Related, but that would mean I'd need to point to a Work Item in my Test project instead of an artifact. I've also tried adding a Related Artifact, but I'm not sure what to use for the URI.
Thanks.
-Jim
I have shared my Test project with the developers, and they can load Eclipse projects within it to get at the various parts that are of interest to them. When I find a bug, I want to be able to share code or other artifacts from my Test project by changing the status on one of the Developers Work Items, putting notes in the Discussion of that Work Item, and then including a link to the artifact in my Test project.
Is there a good way to link to my artifacts? I've tried going in to the Links for the Work Item and Adding Related, but that would mean I'd need to point to a Work Item in my Test project instead of an artifact. I've also tried adding a Related Artifact, but I'm not sure what to use for the URI.
Thanks.
-Jim
2 answers
Hi Jim,
what I was able to do, was using the SCM Web UI, browse a stream for a file, copy the link location and add that as a related artefact. The develoer could click on it and it would open in the Web UI.
I am not sure that is what you want to do. I am not aware that it is possible to associate a file to a work item other than as
- Web URL (related artefact) like described above.
- Change set (not the actual file, but the change that is done to it and the other files in the change set)
- Attachment.
what I was able to do, was using the SCM Web UI, browse a stream for a file, copy the link location and add that as a related artefact. The develoer could click on it and it would open in the Web UI.
I am not sure that is what you want to do. I am not aware that it is possible to associate a file to a work item other than as
- Web URL (related artefact) like described above.
- Change set (not the actual file, but the change that is done to it and the other files in the change set)
- Attachment.
Ralph,
Thanks for the response. All of those seem a bit clunky, unfortunately.
- The Web URL seems extremely long, and would force the developer to use the Web interface, while over half of them on my team prefer to use Eclipse.
- The change set seems the cleanest, but if an existing test if failing and nothing's changed in the test code, there doesn't seem to be a need to create a change set.
- Attaching an artifact seems fine if it's just example/throwaway code, but if an existing test case is failing I'd rather not have multiple copies floating around. Perhaps the change could just be adding a comment about the defect.
I'm wondering if this is all pointing to a deficiency in how I've set up my Test project as a separate project from the Development projects. I'm not sure how I'd re-architect my structure to better coordinate with the developers' Work Items, though. Most of my tests will be integration tests and won't be associated specifically with one subsystem, so they wouldn't belong in the subsystem projects.
After chatting with one of my Lead Developers, I think I'm just going to put a description of where the test is located in my project in the Description of the Development Work Item. They're going to need to load parts of my project to see my tests, anyway. If that fails to work for them, we'll look for another solution.
Thanks again for the response.
-Jim
Thanks for the response. All of those seem a bit clunky, unfortunately.
- The Web URL seems extremely long, and would force the developer to use the Web interface, while over half of them on my team prefer to use Eclipse.
- The change set seems the cleanest, but if an existing test if failing and nothing's changed in the test code, there doesn't seem to be a need to create a change set.
- Attaching an artifact seems fine if it's just example/throwaway code, but if an existing test case is failing I'd rather not have multiple copies floating around. Perhaps the change could just be adding a comment about the defect.
I'm wondering if this is all pointing to a deficiency in how I've set up my Test project as a separate project from the Development projects. I'm not sure how I'd re-architect my structure to better coordinate with the developers' Work Items, though. Most of my tests will be integration tests and won't be associated specifically with one subsystem, so they wouldn't belong in the subsystem projects.
After chatting with one of my Lead Developers, I think I'm just going to put a description of where the test is located in my project in the Description of the Development Work Item. They're going to need to load parts of my project to see my tests, anyway. If that fails to work for them, we'll look for another solution.
Thanks again for the response.
-Jim
Hi Jim,
what I was able to do, was using the SCM Web UI, browse a stream for a file, copy the link location and add that as a related artefact. The develoer could click on it and it would open in the Web UI.
I am not sure that is what you want to do. I am not aware that it is possible to associate a file to a work item other than as
- Web URL (related artefact) like described above.
- Change set (not the actual file, but the change that is done to it and the other files in the change set)
- Attachment.