Goodnight. I have a CI / CD process in Azure Devops that was working normally. As it is all set up, I, after completing a PR, simply execute a Build from my master branch. After successfully completing the Build, I generated a Release and deployed it.
But now I can no longer generate Release. The option to generate a release no longer appears in my pipelines and the message below appears:
This build will be retained forever by master (Branch)
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
Yes, I noticed that this message is in several regions for some my organizations, like Central US.
But I did not see this change in other regions, like East Asia. I think this should be a newly released change and it has not been applied to all regions. This small change is used to remind us how long the current pipeline will be retained.
If we manually retain the pipeline, the message will updated to the "This build will be retained forever by YouName (user)":
And for the option to generate a release, I have not seen it in the most recent versions, and it can be traced back to the TFS2018 version. I think this feature should be removed for a long time.
At present, when we create a release, we will select the release tab:
Related
We have a scenario where some stages that are auto triggered a specific stage in our Azure DevOps release pipeline is set to trigger manually.
Now, release will be created by a user after setting all the run time variables and all the auto trigger stages will be executed without any issue.
Problem that we are facing is, we do not have option for users to change the values of run time variable/provide input before triggering the "manual trigger stage" after the release creation.
Really appreciate if anyone can help on this.
Note: We know we can change the values by editing the release but due to policy limitation all users are not able to edit the release. Hence, looking for alternative.
Thank you!
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.
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
We use continuous build and deploys up through a test environment, and each changeset is tied to a work item (story). After the build is deployed to an environment, I think we can see every associated story for that build. Question is what has changed, functionally, both for verification/acceptance tests and for release notes, support training, and marketing. This is related to How can I identify which work items/user stories are in a selected build in Azure DevOps? except that we want to know before the candidate moves to a higher level environment and to collect the sum of unique changes since this pipeline last promoted to that environment
For this issue ,you could see related work items in Release stage page. It compares the current release with the previous release and then displays the newly added work items associated with changesets.
Note:If the current release deployed an older artifact, then the difference lists negative work items i.e., the changes that were rolled back from this stage.
In addition,you can also enable Report deployment status to Work for the stages under Option in the release pipeline, thus when the stage completes, it will create links to all work items linked to associated changes.
You can see if this is what you need.For the similar case,please refer to this .
a bit of background first...
I am setting up a versioning numbering system for our project which currently only has a development branch, but we are now moving towards our first deployment. We are using TFS and we use nightly builds on our dev branch.
The way we are probably going to go with this is that when we get ready for a release we take a branch off dev and call it 1.x. This shall be a test branch: we test it, fix it (then merge back to dev), test it some more then when it is all good we take another branch off the 1.x branch and call it 1.0. It is this branch that gets deployed to production. Any fixes in production will be made to the 1.x, tested and then a new branch 1.1 will be made.
My issue is with the testing of the 1.x branch. Before testing the branch will be locked for obvious reasons. My issue is that QA requires that a round of testing be conducted against a "version number" and if testing fails the next round of testing will be against a new "version number." Us developers want to tie the "version number" to the release and testing can iterate over that version...so there is a conflict here.
My first thought is to use the build number as the point in time that the code is tested against. When its time to submit a new version for testing, the 1.x branch is locked again and a build is kicked off and the VSTS number that is generated becomes a "release condidate 1 for v1.0." Mapping the RC to a build we can do manually in a spreadsheet...
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
I am now confused about what is the best way to go here. Is using a build number for a release candidate enough? Does manually labelling serve any purpose here (the only benefit I can see is that we can give it out own name and description)? Can I tell TFS NOT to create a label whenever it runs a build and just do all our own labelling at significant points in time (not every build is going to be a release candidate for example)? If so, is NOT creating a label after each build a bad idea, what does labelling give me?
I guess I am confused about where changsets, build numbers/names and labels all fit in with one another...
This is a broad question but its one of those ones where I am not 100% sure what to ask. Any help appreciated.
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
What you have read is correct. With TFS (unlike, say, SourceSafe), every server action constitutes a 'known point in time' which can later be referred to. You can see what I mean by doing a Get Specific Version... and looking in the Version dropdown: in TFS 2005 the relevant ones I see are Changeset, Date, Label. Now, as you correctly say, every build automatically creates a label. This means that at any future time it will be possible to retrieve the code exactly as it was after any given changeset; at any given date; and when any specific label was applied, thus including when any build was done.
The upshot is that you can use your own labels or not, entirely at your own discretion - the ability to retrieve a given snapshot of the code will be there anyway. I wouldn't suggest trying to inhibit TFS from producing a label for each build (I don't know if this is even possible) - labels cost you nothing.
Your branch 1.x is a consolidation branch which will contain many incremental small evolutions.
Locking the branch is not the answer.
Setting a label (specifically named "for QA test", and locked in order to not be able to move that label, is the usual way to signal the QA team they can build their own workspace and retrieve that exact label.
Then they can begin their tests against the code.
Creating a label after each build is not always practical, since not every build is meant to be tested by QA.