I am following the documentation and added a manual validation task to my YAML pipeline which has 3 stages ( QA-DEV-PROD).
The Manual validation is added to the Prod stage of the pipeline.
task: ManualValidation#0
timeoutInMinutes: 1440
inputs:
notifyUsers: |
[group#name]
instructions: 'Please validate the deployment'
onTimeout: 'resume'
Is there a way, where I can add a condition so the user requesting the release should not approve it"?
I know, I can do that via :
WebUI in Release pipeline
Add approvals based on the environments
However, looking for the option to do this via YAML instead of UI checks.
Any insights on this?
Related
We have two stages , Build and deploy in our project.
Every time user creates a merge request from Feature branch to Master(PROD) ,it starts the pipeline with the build stage and stops for manual action to deploy.
Approval is only set for merge request and after the pipeline is successful it would merge to master.But the developer/approver can start the manual action to deploy without even merge request approval .
I want the user or approver to click the manual button only after the merge request is approved. Is it possible to control this or can i add a stage in-between only for approval?
deploy prod:
<<: *deploy
stage: deploy prod
environment: PROD
extends: .dockerprod
when: manual
I have a requirement of giving multiple teams access to a shared resource in azure. I therefore want to limit how people can publish changes to the shared resource.
The idea is to limit the use of a service connection to a specific pipeline, as per this documentation. However if the pipeline is stored in their own repo the developer could change it. This would not give me enough control. I therefore found that it was possible using a template from a central repo. Using a shared repo, would then allow me to have a service connection solely for the template?
So how I imagine doing the above is I need to grant project X a service connection for my BuildTemplates Repo. But this is basically just access to the repo and to be able to use the shared templates. Then in BuildTemplates repo I can have a service connection for my template A.
Now the developer in project X - creates her deployments and configurations for her pipeline with her own service connection scoped for her resources. Then she inherits a template from BuildTemplates Repo and passes relevant parameters for the template A.
She cannot alter the template pipeline A and only the template pipeline A can publish to the shared resource, because of the scoped service connection. I can therefore create relevant guards for the shared azure resource in the template pipeline A - so I restrict how developer X can publish to my shared azure resource.
does this make sense and is it viable?
The pipeline part in A cannot be edited by developer in X ?
The service connection in A will not propagate out so developer in X can use it in an inappropriate way?
Update
The above solution does not seem to be viable since the pipeline template is executed in the source branch scope.
Proposed Solution
The benefits I see with the above suggestion doe not seem possible, because of the issues. However one can utilise pipeline triggers, as a viable solution. This however results in a new issue. When a pipeline is triggered by Developer Y in Y's repository and it succeeds. Then a trigger is made in MAIN repository and the pipeline in MAIN fails e.g., because the artifacts from Y introduced an Issue. How does developer Y get notified about the issues in MAIN pipeline?
Here is my solution, in same Azure organization, we can create a Azure Project, then create a repo to save common pipeline template.
All the repos in other Azure project can access this pipeline template.
UserProject/UserRepo/azure-pipelines.yml
trigger:
branches:
include:
- master
paths:
exclude:
- nuget.config
- README.md
- azure-pipelines.yml
- .gitignore
resources:
repositories:
- repository: devops-tools
type: git
name: PipelineTemplateProject/CommonPipeline
ref: 'refs/heads/master'
jobs:
- template: template-pipeline.yml#devops-tools
PipelineTemplateProject/CommonPipeline/template-pipeline.yml
Since the inline script of pipeline has 5000 characters limitation,
you can put your script(not only powershell, but also other languages) in PipelineTemplateProject/CommonPipeline/scripts/test.ps1
# Common Pipeline Template
jobs:
- job: Test_Job
pool:
name: AgentPoolName
steps:
- script: |
echo "$(Build.RequestedForEmail)"
echo "$(Build.RequestedFor)"
git config user.email "$(Build.RequestedForEmail)"
git config user.name "$(Build.RequestedFor)"
git config --global http.sslbackend schannel
echo '------------------------------------'
git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" -b $(ToolsRepoBranch) --single-branch --depth=1 "https://PipelineTemplateProject/_git/CommonPipeline" DevOps_Tools
echo '------------------------------------'
displayName: 'Clone DevOps_Tools'
- task: PowerShell#2
displayName: 'Pipeline Debug'
inputs:
targetType: 'inline'
script: 'Get-ChildItem -Path Env:\ | Format-List'
condition: always()
- task: PowerShell#2
displayName: 'Run Powershell Scripts'
inputs:
targetType: filePath
filePath: 'DevOps_Tools/scripts/test.ps1'
arguments: "$(System.AccessToken)"
Notes:
Organization Setting - Settings - Disable Limit job authorization scope to current project for release pipelines
Organization Setting - Settings - Limit job authorization scope to current project for non-release pipelines
Check some option in project setting as well.
So the normal user only access their own repo, cannot access DevOps project, and DevOps owner can edit template pipeline only.
For the notification issue, I use an Email extention "rvo.SendEmailTask.send-email-build-task.SendEmail#1"
I have a stage that uses 6 deployment jobs that can either deploy to dev, staging or production depending on specific conditions.
For deploying to production, I'd like to add manual approvals. I am aware that deployment jobs can specify environments on which you can add manual approvals, but I'd like to approve the entire stage and not each individual deployment job. This way, I can approve the stage once and all 6 deployment jobs can run at once, instead of having to approve 6 times.
Is this possible? The documentation says it should be, but it doesn't say how. Besides, in the YAML schema for stages, it doesn't look like you can specify environments inside stages.
Currently there is no such a built-in feature to approve entire stage in YAML. We can only Define approvals and checks for the environments. The documentation you mentioned is also indicated that this is commonly used to control deployments to production environments.
However, there's already a suggestion ticket to request the feature. You could vote and add your comments for the suggestion ticket to achieve that in future release.
Looks like the ManualValidation task could help you there. Using dependsOn will allow all other jobs to complete before final approval.
Example:
jobs:
- job: waitForValidation
dependsOn: 'previousJobName'
displayName: Wait for external validation
pool: server
timeoutInMinutes: 4320 # job times out in 3 days
steps:
- task: ManualValidation#0
timeoutInMinutes: 1440 # task times out in 1 day
inputs:
notifyUsers: |
test#test.com
example#example.com
instructions: 'Please validate the build configuration and resume'
onTimeout: 'reject'
When defining a GUI release I can make it be triggered by an Azure Artifact, is there a way to replicate this for pipelines in YML?
I am building in one AZDO tenant, pushing universal packages to another tenant, where the release definitions will be defined, I'm hoping this can be in YAML. But I don't see an obvious way to do this at the moment?
I see there is a design document that makes mention of packages, but no further details are provided
https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/pipeline-resources.md
Cheers
Edit-
Is there a way to trigger pipeline using Azure Artifacts in YML?-But I don't see an obvious way to do this at the moment?
Yes, Yes. You are right !
That because the content in this document are speculative, designs, and future features.
If you check the upper level of design document you provided, there is a state:
Azure Pipelines YAML - Design Docs
The design docs within this repo are created at different times during
the development of Azure Pipelines, to support collaborative
contributions to the design process. Designs documents are for,
features considered for implementation but never implemented
already implemented features
future ideas for features
The design docs in this repo may not represent the current state
of an Azure Pipelines feature.
When you check the officially release document YAML schema reference-Resources, it only list:
resources:
pipelines: [ pipeline ]
repositories: [ repository ]
containers: [ container ]
So, Azure Artifacts source in YAML should be a future feature at this moment. Hope MS can achieve it one day earlier.
Hope this answer clear your question.
Build completion triggers are not yet supported in YAML syntax. After you create your YAML build pipeline, you can use the classic editor to specify a build completion trigger.
Reference:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#build-completion-triggers
Though i would suggest you to use below mechanism to trigger the release:
Resource triggers
Resources trigger will be helpful in below scenario:
I would like to trigger my pipeline when an artifact is published by ‘Helm-CI’ pipeline that ran on releases/* branch.
I would like to trigger my pipeline when an artifact is published and tested as part of Helm-CI pipeline and tagged as 'Production'.
I would like to trigger my pipeline when ‘TFS-Update’ pipeline has completed ‘Ring2’ stage so that I can run some diagnostics.
https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/pipeline-triggers.md
Webhook triggers
At the end of the CI piepleing , you can add a task to hit webhook url which can trigger your CD is one way.
Hope it helps.
You can use a multi-stage pipeline to achieve this.
One stage would include a task that will push your artifacts to the feed. The next stage will contain other jobs that you want to be executed after pushing the Artifacts.
eg:
stages:
#Stage for preparing the Artifact
- stage: prepare
jobs:
- job: prepare
pool:
vmImage: xx
steps:
- task: PublishBuildArtifacts#1
inputs:
pathToPublish: xx
artifactName: xx
# Next stage in your pipeline
- stage: build
dependsOn: prepare
jobs:
steps:
- task: xx
Note that the second stage build dependsOn the stage prepare.
ps: Multi-Stage pipeline is currently under preview. If you enable it from the preview feature, you will also be able to see a nice visual representation of the stages.
I am constructing a multi-stage Azure Pipeline in Azure DevOps to build and release my product.
I want to use variable groups in this pipeline, so that I can substitute different configuration values for different deployment environments.
I am unable to authorize my variable groups to be used by the pipeline.
When I manually run a build, I see a message on the summary page telling me the variable group is not authorized:
The Azure DevOps documentation says this is to be expected:
When you make changes to the YAML file and add additional resources (assuming that these not authorized for use in all pipelines as explained above), then the build fails with a resource authorization error that is similar to the following: Could not find a {RESOURCE} with name {NAME}. The {RESOURCE} does not exist or has not been authorized for use.
In this case, on the Summary page, you will see an option to authorize the resources on the failed build. If you are a member of the User role for the resource, you can select this option. Once the resources are authorized, you can start a new build.
I am a member of the User role for the variable group, and I am seeing the message, but I am presented with no option to authorize. Is there something else I need to do? Or is there another way I can authorize a specific pipeline to use a variable group?
The provided solution proposed by #hey didn't work for me because i had to use deployment jobs. I've found a hacky way to resolve this error:
Go to your pipeline
Edit
Click on the tree dots > Triggers
Navigate to the variables tab
Variable groups
Add variable groups
Variable groups can only be accessed if they are imported at the "job" level.
Solution:
I have tested and tried to reproduce your issue. In order to solve it, you need to add the variable group under "job".
Explanation / Analysis:
This is how to reproduce and solve the issue:
First, I have tested with the below yaml script, by adding the variable group to the stage (literally at the same level as jobs):
stages:
- stage: build
variables:
- group: 789
jobs:
- job: run_build
pool:
vmImage: 'Ubuntu 16.04'
steps:
- script: echo Build
With this configuration, I was not able to use the variable group. I got the same issue as you:
I then moved the variable group into the job section of the yaml file:
stages:
- stage: build
jobs:
- job: run_build
pool:
vmImage: 'Ubuntu 16.04'
steps:
- script: echo Build
variables:
- group: 789
With the modified configuration, I was able to see and use the Authorize resources option in the error message:
I had this issue as well, but it was because when I created a variable group under Pipelines > Library, the name in Azure Portal did not match the name in my yml file.