On 2/16/2010 11:38 AM, berndyman wrote:

Hi,

If I open a build result, I see a link which opens the related
changeset. These are the changes compared to the previous build. So
far so good.

However, I don't see a link which opens the related workitems. I know
this can be achieved by using the workItemPublisher-task, but this
tasks requires an extra file (containing the related workitems),
which I want to avoid; I want the tooling to show and decide for me
what the related workitems were.

Is there a way to achieve this?

Thanks in advance,
Berndyman.

On 2/17/2010 9:38 AM, berndyman wrote:

Chemiwrote:
On 2/16/2010 11:38 AM, berndyman wrote:
Hi,

If I open a build result, I see a link which opens the related
changeset. These are the changes compared to the previous build. So
far so good.

However, I don't see a link which opens the related workitems. I
know
this can be achieved by using the workItemPublisher-task, but this
tasks requires an extra file (containing the related workitems),
which I want to avoid; I want the tooling to show and decide for me
what the related workitems were.

Is there a way to achieve this?

Thanks in advance,
Berndyman.


This was done by default when for your Build Process you load the code

using always the same Repository Workspace. If you are seeing the
Change
Sets I think you should be seeing also the WIs. are you assigning the

Change Sets to WIs when delivering the code? Build System gets the
info
from there.

Hope this helps,

Chemi.

Hi,

to see the work items it is necessary to
1. Deliver change sets with work items associated to a stream - preferably enforcing this with a process behavior rule
2. Setup the build definition to use a repository workspace flowing against this stream
3. Setup the build definition to accept incoming change sets into the repository workspace used for building

Everything else should be automatic.

Hi,

Are you saying that when using the same Repository Workspace the workitems should be in the build results?
Currently I build based on (always the same) stream, but there is no link with the workitems in the build results...

Regards,
Bernd.

Hi,

you need to make sure you have no outgoing changes in your build workspace - nobody is used to develop anything with it.
The error could come from changes to source (things not on the ignore list). It would also happen if you create new files in the workspace. This happened to me.

Best would be to create the workspace for just a technical user build being in the project for exactly that purpose.

Could that be the issue? Otherwise, please provide more details on the error.

Ralph

Hi,

to see the work items it is necessary to
1. Deliver change sets with work items associated to a stream - preferably enforcing this with a process behavior rule
2. Setup the build definition to use a repository workspace flowing against this stream
3. Setup the build definition to accept incoming change sets into the repository workspace used for building

Everything else should be automatic.

Hi,

Are you saying that when using the same Repository Workspace the workitems should be in the build results?
Currently I build based on (always the same) stream, but there is no link with the workitems in the build results...

Regards,
Bernd.

Hi,

the intent of that snapshot is to allow you to reproduce the build - if it has errors it is even more important, because you can reproduce it and fix the issues without disturbance due to new incoming changes. You should reconsider your policy.

Ralph

Just FYI: without the buildUUID-parameter the combination of both methods works, but I don't like a snapshot being created before the build actually starts. I only want it to be created if the build was succesful, so at the end of my build. This is done with teamAccept, but it doesn't put the linked workitems into the buildresults...