In my release pipeline having Two artifacts.
Build
Tests
While selecting files under artifact I am using "Release.PrimaryArtifactSourceAlias" and accessing the Build artifact files. but is there any variable we can use to access files under Test artifact.
I have tried with "Release.TriggeringArtifact.Alias" but in Documentation only mentioned that for scheduled and manual releases this value will be empty.
I am afraid that there is no Release Pipeline predefined variable to get the value of the required artifacts Source Alias(Name: Tests).
For a workaround, you can check the sources alias of the artifacts.
Then you can manually set the variable in Release Pipeline.
Then you can use the variable in Release Pipeline.
Related
I imported the SmartHotel360 project from azuredevopsdemogenerator.azurewebsites.net and would like to build and release the project however I have certain warnings. I successfully ran the build pipeline but when I want to release it I see this warning: The version provided for the build artifact source is invalid. I do not know from where to take this version. There is no option in the dropdown.
Using the Azure DevOps Services Demo Generator, we can create same SmartHotel360 project as below.
And it will automatically create a build pipeline and release pipeline in SmartHotel360 project. By reviewing the generated release pipeline: SmartHotel360_Website-Deploy, we can see below default primary artifact: Build - _SmartHotel_Petchecker-Web.
Clicking this artifact we will be redirected to a build pipeline which doesn’t exist, so we need to manually delete this artifact and then re-add our own artifact, as below.
Therefore, after successfully running the build pipeline and publishing the artifacts, we can create a new release, as below.
For the source alias you just need to set the Build Name, also on the version it will be automatically picked if you already have a successful build
Say you have a build and its corresponding release definition on Azure Devops.
Generally, the way it's used is like:
Repository "A" changes -> Build repo "A" -> Release to a given environment
Within this scenario (using only one build artifact), it's easy to trigger deployments (after successful build) for different branches.
But, say you also have a release definition with multiple build artifacts (from different repos), and you want to, changes coming from branch "dev" you want to deploy to environment "Development", but if changes come from branch "hotfix" you want to deploy to environment "Staging".
Something like this
You can play with branch filters on the specific environment and artifact filters on the artifact triggers.
The above scenario works very well for "dev" changes when you define your build artifacts to use "dev" as default branch.
But if you make changes on Repo A (branch hotfix), but not in Repo B, the build artifacts for that release will come from different branches, hence the "artifacts will not meet requirements", cause all changes must come from hotfix branch in order to trigger the deployment.
In my opinion, the "Default Version" of the Build Artifact itself, makes this confusion for the pipeline.
See this image example
That being said, how can we trigger a deployment into "Staging" environment if only one of the triggered changes come from the branch "hotfix" ?
The way I can see, when that happens, "Staging" environment never "meets the artifacts requirements", cause other artifacts will use version from "dev" as it's the default source branch.
Has anyone worked with a similar scenario ?
Thanks for reading my question.
Update:
According to your scenario, the best solution at present is to create two release pipelines to deploy separately, because Artifact A and Artifact B have no dependencies.
In the Continuous deployment trigger of the build artifact, you can set Build branch filters to include the dev and hotfix branches.
Then enable Artifact filters in the Pre-deployment conditions of the stage to set the build branch artifact conditions that trigger the deployment.
Artifact filters: Select artifact condition(s) to trigger a new deployment. A release will be deployed to this stage only if all artifact conditions match.
Does each build pipeline execution create a new base folder under which all code is downloaded, artifacts created?
Does each release pipeline execution create a new base folder under which all artifacts are downloaded?
In build pipeline example below, what is the 1 in the path below? Is it the build number or is it the agent number?
In release pipeline example below, what is the r1 in the path below? Is it the release number or is it the agent number?
Build pipeline -
Build.SourcesDirectory/System.DefaultWorkingDirectory/Build.Repository.LocalPath: The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
Release pipeline - System.ArtifactsDirectory/System.DefaultWorkingDirectory/Agent.ReleaseDirectory: The directory to which artifacts are downloaded during deployment of a release. Example: C:\agent_work\r1\a
Does each build pipeline execution create a new base folder under which all code is downloaded, artifacts created?
With self-hosted agents, no. The first run of a build will create a folder for that build pipeline at {DRIVE_LETTER}:\{PATH_TO}\{BUILD_AGENT_WORK_DIR}\{BUILD_NUMBER} (on Windows). This folder will be re-used for subsequent pipeline builds. In Azure DevOps Services agents, it may wind up being the case that you never build twice on the same agent/host, so the folders will be created each build. See the docs for System.DefaultWorkingDirectory at: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
Does each release pipeline execution create a new base folder under which all artifacts are downloaded?
No. The base folder is created on the first run and recycled for subsequent runs, similarly to the way builds create folders. These will be found at {DRIVE_LETTER}:\{PATH_TO}\{DEPLOYMENT_AGENT_WORK_DIR}\r{RELEASE_NUMBER}.
In build pipeline example below, what is the 1 in the path below? Is it the build number or is it the agent number?
Build number.
In release pipeline example below, what is the r1 in the path below? Is it the release number or is it the agent number?
Release number.
NOTE: The re-use of the folders during the build/release depends on the job being processed by the same agent. In Azure Devops Services (as opposed to Azure DevOps Server), this may never happen depending how short-lived agent hosts are. There may or may not be any affinity between your pipelines and build agents.
A release can be triggered when the build artifact is available as shown in screenshot below.
So does this necessitate that for the release pipeline (configured for build artifact) to get triggered, the build pipeline must have the "publish artifact" task?
Agree with Shayki Abramczyk, the answer is No. But I think maybe you need more descriptions to help you understand ~
In your situation, you set build pipeline as release pipeline's artifact. If you've checked this document you would find these statements:
1.When authoring a release pipeline, you link the appropriate artifact sources to your release pipeline. For example, you might link an Azure Pipelines build pipeline or a Jenkins project to your release pipeline.
2.Note from here:
You must include a Publish Artifacts task in your build pipeline. For XAML build pipelines, an artifact with the name drop is published implicitly.
3.Auto-trigger releases feature(CD trigger in artifact): New releases can be created automatically when new builds (including XAML builds) are produced. See Continuous Deployment for details. You do not need to configure anything within the build pipeline. See the notes above for differences between version of TFS.
To sum up, the artifact source here represents a build pipeline instead of the outputs of a build pipeline. So when you enabled the CD trigger in artifact(in your situation a build pipeline), the release is triggered whenever a new build finishes. And this behavior won't be affected by whether the build pipeline has Publish Artifact task to publish the outputs from it.
For the 2.Note: It can be considered as we must include a Publish Artifacts task in build pipeline so that the release pipeline can access the outputs of build pipeline. And then we can deploy the outputs(.dll/.exe or what) to target machines/environments. (Actually we think the must in document should be replaced with It's recommended to/should)
Publish Artifacts task make the build+release process meaningful. Cause if our release pipeline can't access outputs of build pipeline, what should we use to deploy? But whether this task exists or not won't actually affect the CD trigger. (Just like the third statement:You do not need to configure anything within the build pipeline)
The answer is No, the release will be triggered when the build finished even he doesn't have Publish Artifacts step.
I have a release pipeline which i use to deploy my resources to other environments. All works fine but the problem is that every time i deploy, all the resources even if no modification is made, are deployed. Is there a way through which i can do selective deployment; i.e. I deploy only those resources which have been modified. Any help would do. Thanks.
That`s a broad question. There is no out-of-box feature to select units to deploy. But you can use variables in the release pipeline:
Define a variable for each resource/unit and set some default value and "Settable at release time" property.
For each resource, define a separate task to deploy and define the custom condition, like: and(succeeded(), eq(variables['Custom.DeployUnit1'], 'YES'))
You can update these variables at the release creation time:
Is there any way to do selective deployment in azure devops?
There is no such out of box way to selective deployment in azure devops.
That because Azure devops release does not support release only changed files since only release changed files not always meaningful and could not archive what the project intend to release (such as the config file only changed in a commit).
But you could create a PowerShell script to compare timestamp for all files:
Create XML file that stores the last upload/publish information of
each files (e.g. file name, date time, changeset/commit version).
Create a PowerShell script file that included the logical to compare
files (get files metadata and compare with that XML file) and copy
updated files to specific folder
Publish the files in that folder
Check the similar thread for some more details.
Besides, if deploying via the deploy.cmd or MSDeploy.exe, you could also use the the -useChecksum WebDeploy flag:
WebDeploy/MSDeploy Quick Tip: Only Deploy Changed Files
Hope this helps.