I am trying to accomplish the following:
When I kick off a release of a build, I want to include the previous release with the latest one. What I am trying to do is run a script inside the release that compares the two files and outputs a combined file with additions and deletions highlighted. I have a script that will accomplish that, but im not entirely sure how to get yesterdays artifact with todays artifact do complete the release.
I was thinking about tagging but maybe someone has a creative idea.
Using tags is a way to distinguish the dates of artifacts.
The artifact itself also has a parameter to distinguish between versions.
In Release Pipeline, you could add two artifacts from the same Build Pipeline.
For example:
The version of artifacts is distinguished by build number. You could select the Specific version and choose the target version for the two artifacts.
Then you could download the old and new artifacts in one release pipeline.
Note: You need to change the Source Alias for each artifacts. They need to be different.
Related
Is it possible to define just one release pipeline for all the packages of one feed ?
A feed contains artifacts of the same kind (i.e. Debian package). Which means the release process usually is identical. Well, at least, in my case it is. So I'd rather not copy/paste release pipelines for each and every package. But rather define a system wide way of deploying artifacts of one kind.
I've tried to set the trigger's package name to wildcard values. The input is accepted but no release is launched.
The release pipeline looks like this:
There are various build pipelines making rpm packages. Those publish the rpm files into a feed (e.g. linux_rpm). The release pipeline I'd like to have is waking up for every artifact in the feed. Instead of waking up for one specific package.
Is it possible to define just one release pipeline for all the
packages of one feed ?
For this issue, the answer is yes. We can add multiple Azure Artifacts type artifacts. In this way, all packages in a feed can be used as release artifacts.
Azure DevOps release pipelines let me specify multiple input artifacts but automated triggering only happens for the primary artifact. Is there a way to do a 'wait all' type operation on N input artifacts so that my release pipeline only starts when each artifact has a version available that matches some specified value?
For instance, say I make a commit M in a repo which has multiple different CI jobs A and B which take very different amounts of time. One CI job (A) creates a NuGet package as an artifact in minutes, the other CI job (B) takes hours to create VM images. I want a release pipeline which will use the NuGet package and VM image as inputs. But if I simply use the latest version of A and B as an input artifact in a release pipeline with a CI trigger on the primary artifact (either A or B) then when the release triggers it could be using mismatched versions of artifacts as 10 NuGet packages from 10 different commits are complete before I even get 2 VM images made by the other CI pipeline. I thought maybe build/artifact tags could solve this so that my release waits for artifacts which all have the same tag but I can't use variables in build/artifact tag filters which makes this not really amendable to any sort of automated scheduled/trigger.
Is this some good pattern for this type of workflow?
For this issue , based on your workflow, I am afraid that it is impossible to achieve a fully automated release. Enabling the Continuous deployment trigger will create a new release every time when a new build is available. Since the two artifacts are not generated at the same time, the two matching artifacts cannot be used as the source in automatic release.
To use specific artifacts as source in a release, we usually specify the version in Artifact. But this can't achieve continuous deployment. One way is to merge jobs A and B to generate an artifact, so that you don’t need to worry about the corresponding issues of artifacts, but according to your actual situation, I ’m not sure about the feasibility of this.
do a 'wait all' type operation on N input artifacts so that my release
pipeline only starts when each artifact has a version available that
matches some specified value
Apart from the negative answer, I think what you want is a good idea! So I post a feature request here in DC forum. You could vote that suggestion ticket and share your comment there.The product team would provide the updates if they view it. Thank you for helping us build a better Azure DevOps.
I have an ADO build pipeline that builds three artifacts. However, while I am developing, I only want one of the artifacts to be built since that is the artifact on which I am working and it takes longer for all of them to build and I don't want to wait. Can I disable the other artifacts from building?
As I know, you could not use UI to disable some of artifacts which build from one build pipeline. Because we does not provide this feature in VSTS now.
But as workaround, you can use Copy File task in your release to achieve this.
Specify the artifact what you want to work with in release pipeline, and copy it from File A(the source file where these build artifacts is) to File B(any file you want). And then, you can do other thing with this specific build.
Hope this could help -)
When you are using the online Visual Studio Team Services for the build/release process, I find the window/wizard for creating a new release to be a bit limiting. At the moment for me, when I want to pick which version of an artifact(s) I want to release it only lists the build version number, which is a pain when you have multiple artifacts built from different branches and don't necessarily always want the latest build of each.
Is it possible to customise this build version dropdown to include something else (like the branch it was built from)? I've tried changing the output artifact name in the build definition, thinking maybe that would be picked up in the release wizard, but it isn't.
Change the build name output format on the Options tab of the build definition. The variable you're looking for here is $(SourceBranchName).
As an example:
$(Date:yyyyMMdd)$(Rev:.r)-$(SourceBranchName)
I have a VSTS release definition that I want to use for publishing nuget packages for multiple artifacts. The artifacts for the different nuget packages are supplied to the release definition from different build definitions. Only artifacts from the build that triggered the release shall be downloaded and published. The pipeline is setup according to the picture below.
That is, when a build triggers a new release, only artifacts from that build should be published in the release. All artifacts from the other build definitions should be ignored since the version number on those nuget packages are not updated and will fail to push.
Can this be accomplished?
Take a look at this link https://learn.microsoft.com/en-us/vsts/release-notes/2018/mar-05-vsts#improve-release-times-by-partially-downloading-artifacts
And then on that same link see Deploy selectively based on the artifact triggering a release
It will basically explain VSTS new features. The first one is to specify what you want to download on a release phase. The second one is to add a custom condition on a phase to define if it should be executed.
So you could create two phases, one for each of your artifacts. Each phase would only download the corresponding artifact and only run if the custom conditional evaluates true, using the new release variable Release.TriggeringArtifact.Alias.
Note that this release variable is only present if the release is continuous deployment.