I'm running builds with AzureDevops piplines. When I'm creating new pipline I'm not queueing it and just saving. If CI trigger is selected pipline will run if anything is checked in.
But on the very first run/chack-in pipline will be liked (associated) to ALL check-ins (changesets/commits) that happened before the current one and to all workitems of those chack-ins.
This behaviour is not desired for me. Is there a way to disable it?
On all subsequent check-ins build will be associated only with the one that triggered the pipline. And this is what I want for the first build as well, for it to be associated only with the chack-in that triggered it.
Without seeing exactly what's happening, it's hard to provide advice. It could also behave differently if you're using Git or TFSVC variants. Here's a few things to try:
Disable the CI trigger, do your first check-in, then re-enable the trigger. That might skip the change-set and work item affiliation one time.
Delete the offending build after it runs or do the laborious task of manually deleting all links in it.
If you're using Git, you can also limit the CI trigger by using a Pull Request with Squash merge. This will consolidate the commits down to one.
There isn't the way to disable it. It would compare previous run, then include all changesets between them. So, for first run, it must includes all previous changesets.
You may create a new branch for a folder, then configure build for that branch. Learn about branching strategies for Team Foundation Version Control (TFVC) and how to select an effective strategy
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.
I am wondering why my build pipeline for Azure DevOps is getting practically all the changes instead of just the most recent one?
I only made one change to 1 file, that didn't have an associated work item. This is what the change looks like. As you can see I have only changed one file. So why is it detecting all the changes?
I thought maybe it was because I didn't have this option enabled.
But even with that option enabled on a pipeline setup the EXACT same way all the changes are still pulled. Am I missing something subtle here?
There's an option on the pipeline to automatically link work items that are completed in a run.
You can edit the Pipeline and in the settings, tick Automatically link work items included in this run. You can pick * for all branches, or a specific branch.
Not sure what you did for your pipeline. Every time you change the files of repos for pipeline and then re-run the pipeline, it lists the changes for each build for the current project. This depends on how many changes you have made to the repo project since the last pipeline.
The below shows:
Then, click into the latest pipeline, and that is true, it will list all changes compared to the previous pipeline.
Click into it and you could get the detailed every single change.
In VSTS builds, is there a way I can know who have make changes in build steps?
Can I get history builds?
The reason for this is, we have a big team. Many time it happens that someone changes the build step for some reason and we never know who made the changes and why.
Like in git repo, we know which file is changed by who and why (in comments).
In VSTS builds, is there a way I can know who have make changes in build steps? Can I get history builds?
The answer is yes. You could check the History of the build definition:
Click on the three horizontal dots and we will get an option compare difference, through which we can know the details of the pipeline modification. If the modifier adds a note when saving the modification, we can also know the reason for the build pipeline modification.
I'm pretty sure this setup was working at one point for us. I changed our builds a bit to reflect some operational changes and now the CI git branch trigger isn't working. I'm trying to get it so when a PR is merged into master it triggers the release build. I can trigger this build manually but not when submitting a PR to master from dev and then accepting the PR (on github).
Is anyone else having issues or know whats wrong?
Adding an answer so this more visible. #starain-MSFT comment was the solution.
I added a new build with the same trigger and it fixed the other one not getting triggered. Then deleted the new build I had added and everything is working.
Cloning my build definition didn't work, unfortunately, and neither did saving a trivial change to the build definition. Instead, I had to explicitly disable the CI trigger, save, then re-enable it and save it again. (Annoying, because I had to redefine all the rules.) But give it a try if the accepted answer doesn't do it for you.
I also wonder if adding a random branch to the triggering branches list, saving, then removing the random branch and saving again would work (and save you from having to redefine everything).
UPDATE 2017/02/28
The tags in the release triggers are not source control tags, they are tags that can be generated by your build step. You can tag your builds automatically (see below), or manually during a build, I haven't tried this yet.
My assumption about the tags were flawed, which makes this question pretty much invalid. However I am going to try and see if I can find some sort of workaround for my exact scenario, and then I will post it here.
Background
I am setting up our CI/CD pipeline using VSTS, and part of our branching strategy is that only release/* branches that are tagged will be deployed to production.
Problem
I am trying to trigger a release using the VSTS Continuous Deployment feature, which should be able to work with branches and tags. At first I tried this, thinking that I could use a wildcard for everything:
Attempt 1
The trigger never worked, so I decided that it is probably not supported (because I can't find any documentation around it). So I tried an explicit tag.
Attempt 2
That didn't work either, so I decided to abandon the release/* wildcard altogether and just attempt it with a specific release branch.
Attempt 3
Still didn't work. I am either missing some really important steps here, or it is broken. Please help.
PS - For every attempt, I made sure that I committed a new file in git, tagged the commit, and kicked off a new CI build.
PS - Specifying a wildcard for branches like release/* works perfectly, as long as you leave the tag field empty
It is filtered by the build tag instead of source tag/label.
For example, a release definition CD with myTag filter, then the corresponding new build need to have myTag.
To add the tag to build, you can refer to these steps:
Edit your build definition
Add PowerShell step (Inline Script: Write-Host "##vso[build.addbuildtag]myTag")