I see this feature is available, but I can't seem to get it to work the way I expect it to. Am I misunderstanding the capabilities of this feature?
When creating a build pipeline there is an option (since 2017) to automatically link a build to work items. Under this option is an Include and Exclude list for branch specifications. The default is Include * which searches all branches for work to link since the last successful build.
I'm trying to implement a branch naming convention because we have many solutions in the same repository and don't want work items relating to system 1 to be linked to the build of system 2.
To do this I'm using an Include sub2/* branch spec, but the build doesn't seem to link correctly.
Custom Branch Spec
Change on Branch Outside Spec
No Other Commits Linked to the Work Item
The Work Item Still Shows on the Build
BUT the build doesn't create an Integrated in Build link on the work item.
For changes made WITHIN the branch spec
The functionality of the build showing the work items in the progression (seen above) includes the work item as expected, but the Integrated in Build link is still not added to the work item.
Related
My question is a continuation to this post:
Close work items automatically on Release to specific environment
This accepted answer will work perfectly, but only if I can make sure that a build shows just the delta since last build as associated WorkItems, instead of all work items from history. Sometimes I see all items in history as associated work items in a build.
Builds are happening for several environments (Dev, QA, UAT, Prod). How do I make sure that when I run a new build, it only has delta since the last build in that same environment so that I am only looking at new changes that are coming in with a new build?
Update:
I think I get what you mean. Please see if my understanding is accurate: your master branch has many PRs and links to many workitems. You create release1 from the master, and then when the branch is run based on release1 for the first time, the API lists the associated workitems of all the commits of the master. The second time, the incremental workitem compared to the first time can be displayed normally. Later, you created release2 from the master. When the branch was run based on release2 for the first time, the API listed the associated workitems of all commits of the master(This is not you want.). The second time, the incremental workitem compared to the first time can be displayed normally. . What you want is to display incremental workitems from the last run of the branch based on release1 the first time the branch is run based on release2?
If so, it's obviously not possible to use this API to achieve the requirements. As I said in the answer, this API fetch increment refers to the increment based on the same branch, it does not apply to different branches.
But you still have a way to get the "increment" you want, check out this API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-work-items-between-builds?view=azure-devops-rest-6.0
You just need to compare.
Original Answer:
but only if I can make sure that a build shows just the delta since
last build as associated WorkItems, instead of all work items from
history. Sometimes I see all items in history as associated work items
in a build.
Why do you say 'make sure'?
The API should only get the delta workitems(under the same branch).
I think changes should not contain all of the work items linked to all of the previous commits(since it is only 'changes').
Do you mean the behavior on your side is unstable, do you mean sometimes contains delta changes but sometimes contains all of the changes during the branch lifecycle?
If not, then the understood of yours maybe a little false.
If yes, I think you need to report this issue to the Developer Community. Please also provide your problematic build url there in this situation. StackOverflow is an open forum, so it's not suitable for handling stuff with private information.
Builds are happening for several environments (Dev, QA, UAT, Prod).
How do I make sure that when I run a new build, it only has delta
since the last build in that same environment so that I am only
looking at new changes that are coming in with a new build?
I suggest you put each environment in a different branch, then when you run pipeline based on the related branch, the pipeline should only get the delta changes of current branch and the API should only get the delta workitem commits since the last pipeline run of current branch.
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
Fill in a changelog dynamically
Stop deployment if there are an issues part of the Release that are not Done
Retrieve version numbers
Question: Is there a VSTS equivalent?
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.{YourFieldName}' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
In Project A, I setup a build to automatically link the build to associated workitems...worked flawless the first time.
In another project - I have a build-definition which does not set the link.
What's curious - a clone of said definition, with some tasks removed (basically just "Upload Artifacts" removed, cause it is just a build-verification test for pull-requests) does set the link.
I even re-created the build-definition from scratch, still no links added sigh
Anybody have any insights on these problems?
Also - I ran the build in "debug" mode, with detailed logs...could not find any information which would be helpful.
Thanks in advance
Johannes Colmsee
Update: there is another task I removed from the "Build-Verification" Build-definition: publish symbols
Update 2: for brand new build-definitions, I will get a warning telling me that the link was not created because too many changesets were associated…for subsequent builds though...no warning, but also no link sigh
Update 3: also - I can manually select the builds for "integrated in build" link in the workitem - so...they could potentially be added automatically too I suppose...
Update 4: the subsequent PullRequest and the following builds all associated OK to the workitems….so it was probably my fault.
The warning message in your Update 2 should be the reason. "Automatically link work" feature compares the changes and work items between the current build and previous build. When the count of changes or work items is more than 200, it will not link. When you create a new build definition and run a build, there is no previous build which means that all the changes and work items in your code repository are calculated. And also if there is no change or no work item linked in the change in the subsequent build, it will not link any work either.
We have a lot of Build Definitions and i want to create a category or a subfolder to make less mess (what a phrase) in our Project
this image shows only half of our build definitions and i really want to clean up here!
i've tried the context menu (right mouse button) but i didn't find any useful items there.
There is no "subfolder" option, for build (for grouping builds together) or even source control (for grouping streams together) in RTC (3, early 4).
The "Administering Rational Team Concert Builds" only suggests tagging builds
You can tag builds to organize them or identify them for search purposes.
You can also select a tag from an existing list of tags.
A tag is a single word with no spaces.
A build result can have multiple tags associated with it
Update 2015: as mentioned in Enhancement 217033 (even though it was triaged in Enhancement 303863), also mentioned in Task 303722:
RTC 4.0.6 has the capability to organize build definitions into build folders.
RTC 5 has that feature fully implemented, as mentioned in Enhancement 300232.
The OP Martin Frank adds this image:
Once a folder is created you can drag&drop the build definitions into the desired folder.
We're using RTC/Jazz SCM and I'm the Configuration manager in our team...
So I setup the RTC/Jazz SCM, I created a component, I created a stream, I created a repository workspace and a local workspace, the repository has the stream as flow target.
After I shared an eclipse Project I did some other changes and my component grew and grew...
I made baselines whenever I made a build. Now my coworker are asking me: how can I know if my file is in this or that build, and I'm not sure how to answer their question, so
How can you show all BASELINEs on a FILE?
The article "Practicing source control archaeology with Rational Team Concert" shows that a file History view only shows change set, not baselines:
If your change set is linked to a work item, that work item id will be part of the change set title.
And it is better to consider work items instead of files, because for a given build (see this thread), you can use the "Work Items link",the one in the Contribution Summary section of a build result.
You can then have a look at "Work items included in this build": work items whose change sets are included in the configuration being built.
This differs from "Work items reported against this build" (top right corner of a build result), which are ones that you explicitly associate with the build (commonly, work items that created after the build was completed, that refer to information generated by this build, such as errors reported in the build results).
So there isn't a direct way, but looking at a build result can help find a work item you know your file is a part of.
Scott Cowan adds in the comments:
you can easily get to a change set's work item to find it's build results by:
selecting the file version in the History view and
in the context menu select "Related Artifacts > Open".