related workitems in build results

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.

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,

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,

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.

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,

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.


If I am not wrong, you should create a Repository Workspace to be used
by the Build. When the Build updates the Repository Workspace with the
new content from the Stream, it registers all the new Change Sets and
their WIs associated and they are published as part of the Build Result.

With that way of work, it is working for me.

Hope this helps,

Chemi.

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,

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.


If I am not wrong, you should create a Repository Workspace to be used
by the Build. When the Build updates the Repository Workspace with the
new content from the Stream, it registers all the new Change Sets and
their WIs associated and they are published as part of the Build Result.

With that way of work, it is working for me.

Hope this helps,

Chemi.



Thanks for your help guys!

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 Ralph,

If I use the teamAccept-ANTTASK for creating my snapshot, I need to unselect the "accept incoming changesets into repository..." otherwise I will have an error I'm trying to create a second snapshot on a same buildUUID.
So I need to use one of both options.

However...

If I do accept incoming changesets in the repository workspace prior to build, I have workitems in the buildresults.

If I don't and use the teamAccept-ANTTASK, no workitem is linked into the build results.

Any thoughts?

Thanks in advance.

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 Ralph,

If I use the teamAccept-ANTTASK for creating my snapshot, I need to unselect the "accept incoming changesets into repository..." otherwise I will have an error I'm trying to create a second snapshot on a same buildUUID.
So I need to use one of both options.

However...

If I do accept incoming changesets in the repository workspace prior to build, I have workitems in the buildresults.

If I don't and use the teamAccept-ANTTASK, no workitem is linked into the build results.

Any thoughts?

Thanks in advance.

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 Ralph,

If I use the teamAccept-ANTTASK for creating my snapshot, I need to unselect the "accept incoming changesets into repository..." otherwise I will have an error I'm trying to create a second snapshot on a same buildUUID.
So I need to use one of both options.

However...

If I do accept incoming changesets in the repository workspace prior to build, I have workitems in the buildresults.

If I don't and use the teamAccept-ANTTASK, no workitem is linked into the build results.

Any thoughts?

Thanks in advance.


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...

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...

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...

I agree that snapshots are important for reproducing (the) build(workspace). However, I'd prefer to let a buildscript perform the teamAccept (and create a snapshot) after or before certain other actions on the requested build.
Shouldn't the teamAccept-task behave exactly the same as having the "accept changesets"-checkbox checked for the buildengine?

thanks in advance.