In VSTS online, I have in my Release process (Under Triggers) the Continuous Deployment checked. On the Set trigger on artifact source, I put a Tag condition (with tags) set to Automated.
I also have a tag in the Build Process. (Correctly adds the Tag to the build)
But my release is not triggered automatically? In the Deployments status (In my Build) it says "Tags set for release trigger did not match the tags in build branch". But they match (See pictures). What could be the issue?
This is because you added the tag Automated after the build is finished (by label source or manually). This can’t trigger CD release. Tags should be add during a build (not a build is finished). So you can add a power shell task with inline script in your build definition:
Write-Host "##vso[build.addbuildtag]Automatd"
Then the release will be trigger after build is finished.
I do this a different way very similar to:
How to trigger VSTS build and release when pushing tags?
In my Release Pipeline I add a branch filter to 'refs/tags/' or 'refs/tags/v' for the Continuous Deployment Trigger, or anywhere else where I want to filter action in my Release Pipeline. The good thing is that you can apply your Git Tag AFTER your build is complete, just like you prefer. This is optional, but I use Git in conjunction with GitVersion.
Also, please be aware that Git Tags and Build Tags are not the same. Git Tags are stored in the Git repository while Build Tags are associated with a VSTS/Azure build summary. Don't get confused with the two.
For future readers it looks like you can now trigger a release even when a tag is added to a build at any time (not just during a build).
Create a release when tags are added to an existing build. Upon enabling this option, a release gets created when tags are added to an existing build that has not been released. This could lead to deployment of an older build to the environments.
Related
I'm trying to understand how the option Build tags works inside the Continuous deployment trigger of the release pipeline.
build tags
Here I can add Build tags, in my build pipeline is set the following build tags: $(Build.DefinitionName)_$(Build.BuildNumber) But when I put the same inside the build tags at the Release pipeline. It won't do anything.
The tag's are succesfully added: tag
What I'm trying to archive is that when a build is successful a tag is created and the release pipline is triggered when the tag is the same as the one I set after the build.
Is this how it should work, or do I mix thing up?
It is doing an exact name match of the build tag. If you wanted this to work, you'd need to put the hard-coded build number. Not the template for creating the build number.
For my product, we build in both debug and release configurations. I will stamp a tag either { debug, release}. Then on the release pipeline, you might have the build tag only flagged for { release }, so you don't ever deploy debug copies.
Last week, our team decided to move all separate .NET projects into a single solution. Because we were already using Azure DevOps with separate build pipelines for each project, we looked into the possibility to only trigger builds whenever there are changes to a specific project. This, to prevent the build agents from rebuilding the entire solution on every commit.
Because our source repository is a locally hosted Git one, we do not have the niceties of using path filters, so we resorted to using a Powershell task to determine if all upcoming tasks should be skipped, using a custom condition (explained in this SO question).
Now, on every commit, all builds are triggered, but the builds resolve for themselves if they should continue to build and (more importantly) if they should publish a build artifact at the end. An example of such a skipped build is below:
However, every time such a build 'succeeds', a new artifact is created, even though the publish artifact task is skipped. The problem is that all our release pipelines are triggered when a build pipeline creates an artifact. So every time a build is skipped like shown above, the release pipeline triggers and tries to deploy the artifact. But it fails, because the artifact it uses to deploy does not really exist (it seems like it is empty, and the build pipeline actually doesn't mention an artifact on the Summary tab), so any operations on the artifact fail in the release pipeline.
Our release pipelines are set to trigger on source type build artifact, for the corresponding build pipeline, with the default version parameter set to latest.
How is it possible that, even though the publish artifact task is skipped, the release pipeline still triggers and tries to deploy an empty artifact?
I assuming you enable the Continues Delivery in the Releases pipelines, this option is not related to build artifacts. this option means that Release will be triggered when the build succeeded (not matter if he has artifacts or no).
So this is the reason why after each build a new release started.
As workaround, you can add a task in the build that add "build tag" only when there is a artifacts, and in the release artifacts options, instead of choose Latest you can choose Latest from the build pipeline default branch with tags and specify the tag you put in the build.
Another option is in the "Stages" click on the triggers and then it's configured to "After release" so enable the "Artifact filters" and specify there the build tag.
How do you add a build tag? add a PowerShell task with this command:
Write-Host "##vso[build.addbuildtag]test-tag"
I have branch validation in the form of a PR Build, which means I have duplicated my original build and removed some steps (such as pushing to my docker registry).
I would prefer to simply be able to automatically add a tag / some kind of identifier to a PR build and exclude the step on the original build using custom conditions.
Does anyone know if this is possible, and if so how to achieve it? I'd really rather not duplicate each and every build.
If I understand your question correctly, you would like to run a build step based on a custom condition. In this case, the custom condition is whether the build is a PR build or not.
You can check the pre-defined build variables available in Azure Devops here and you can see that there is a Build.Reason variable.
I am listing a few variables here.
Manual: A user manually queued the build.
IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.
PullRequest: The build was triggered by a Git branch policy that requires a build.
You can specify the condition in custom condition settings of your build step like this.
More examples available in the docs
I try to set up continuous delivery with VSTS and Azure with the following workflow:
Build on every commit to master (CI)
Create new release (and deploy) when a release tag is added (CD)
I have looked into:
This answer suggesting to check the box, which doesn't
work.
An other answer which configures the build, but I want to use a release.
And this one, which adds a custom build task, but does not use releases.
The build part works fine, and I can create a new release manually. But I can't get the release manager to create a new release when a new tag is created.
I have configured the deployment trigger like this, but it doesn't trigger on new tags even when the Create a release when tags are added to an existing build:
I have tried Build tags variations as refs/tags/v*, refs/tags/v\*, v*, v\*, and specific tags like prod.
My build only reports Tags set for release trigger did not match the tags in build branch, which isn't very helpful:
I think the confusion is about the type of Tags. Build tags are actually defined on the Build, not in Git. They're not the same thing as a Git tag.
You can set the Build Tags through the REST API or through the UI (add tags on the Build Details page).
For more information, see:
Controlling build quality using Build Tags and VSTS Release Management
Tags - Add Build Tag
In order to release based on tags, I think you may need to configure a CI build to trigger in the tag, then feed that into the release workflow. There is no way, without custom scripts, to promote the Build automatically by pushing a Git tag.
I have a project hosted on GitHub and I have it compiling with Appveyor.
I would like to set up Appveyor so that each build is deployed as a GitHub release, but with each build overwriting the last. This way there will only be one GitHub release from Appveyor that will always have the latest build attached.
I can't see how to do this, because if I specify a release in appveyor.yml I get an error saying the release already exists (yes I want to overwrite it), and if I don't, then each deployment creates a new tag with the current build, which will litter the repository with useless tags.
On top of that, every time the release gets deployed, it creates a new tag which in turn triggers another Appveyor build. This means every push to the repository triggers two identical builds.
Has anyone worked out a way to deploy to the same GitHub release continuously, replacing the files with the latest versions, and to prevent a new Appveyor build from being triggered in response to an Appveyor deployment?
You can add force_update: true to GitHub deployment provider settings to overwrite existing release.