I can't get the Azure Devops trigger to work - azure-devops

I will try to explain in the best way.
First situation: I didn't find any task to insert my yml file which is in ruby. If I choose Ruby, I can't edit the yaml file. If I can edit that file, I should make this trigger fire. It actually fires, not with the yml file I want
If I use the other way I can't save because I don't have permission to run pr on the master branch. My pipeline doesn't run automatically just manually
enter image description here
enter image description here
My yml:
# Ruby
# Package your Ruby project.
# Add steps that install rails, analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/ruby
trigger:
branches:
include:
- homolog_gso
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UseRubyVersion#0
inputs:
versionSpec: '>= 2.5'
- script: |
gem install bundler
bundle install --retry=3 --jobs=4
displayName: 'bundle install'
- script: bundle exec cucumber -t #incluir_setor_resp_em_branco
displayName: 'bundle exec cucumber'
- task: PublishTestResults#2
inputs:
testResultsFormat: 'NUnit'
testResultsFiles: '**/TEST-*.xml'
mergeTestResults: true
searchFolder: '$(Common.TestResultsDirectory)'
testRunTitle: 'Regression Test Geocall Gab'

When creating a new YAML pipeline and selecting the provided template to generate a initialized YAML file, by default this YAML file will be saved into the default branch of source repository (such as master, main).
If you do not have the permissions to directly edit files in the default branch, you are surely not able to edit the YAML file saved in the default branch.
you should copy / create the YAML to another branch where you have the permissions to edit files (e.g. homolog_gso). Then create a PR to merge the changes from this branch to the default branch.
About the PR trigger in your case, you can set the PR trigger like as below in the YAML file from the homolog_gso branch:
pr:
branches:
include:
- master
. . .
By this way, if you push some changes to the homolog_gso branch and then create a PR to merge the changes to the master branch, the PR trigger will fire to run the YAML pipeline.

Related

CD Yaml build is triggered for branch in filter, but builds default branch

I have 3 Yaml Pipelines:
CI1 that should be build on any commit to services/* branches
CI2 that should be build on any commit to services-release/* branches
CD that should do the deployment of the artifacts created by CI2
CD is setup the following way:
YAML Settings
Triggers Settings
As you can see, I've tried different formats of the branches to branch filters. Even if I add non-wildcard filter, I still see the following behavior:
CD pipeline is triggered after CI2, triggered by commit into services-release/* branch (which is correct), but it releases latest build from a branch, specified in "default branch for manual and scheduled builds" dropdown - which is develop in my case.
What should I change to deploy the artifact that was generated by CI2 build from services-release/* branch?
Judging by the pictures, you are using yaml-pipelines but classic pipeline triggers. While this works for triggering the pipelines, you might want to consider implementing the triggers in yaml files for C1- and C2-pipelines.
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
As for the yaml-based CD pipeline, in order for the pipeline to trigger upon completion of CI2 and for it to download artifacts from the triggering run (instead of latest from the default pipeline), you should reference the CI2-pipeline as resource:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops
So something like:
resources:
pipelines:
- pipeline: ci2_pipeline #this is used to reference this resource in CD pipeline
source: CI2 #Rename this to match your build pipeline name
trigger:
branches:
- services-release/*
For the artifacts, you want to ensure that you are using Pipeline Artifacts instead of classic build artifacts and use the Download Pipeline Artifacts -task in CD-pipeline (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-pipeline-artifact?view=azure-devops). So something like:
steps:
- download: none # Disable downloading default artifacts
- task: DownloadPipelineArtifact#2
inputs:
buildType: "specific"
project: "$(resources.pipeline.ci2_pipeline.projectID)"
definition: "$(resources.pipeline.ci2_pipeline.pipelineID)"
preferTriggeringPipeline: true
buildVersionToDownload: "latestFromBranch"
branchName: "$(Build.SourceBranch)"
targetPath: "$(Pipeline.Workspace)"

Azure pipeline, muti stage YAML pipeline using same work directory on build server. How does it not corrupt

Clarifications and corrections:
Testing with one self-hosted agent.
By version I mean version of the application. Or any new commit.
The same work directory is being used for builds of different commits, when there are still pending stages (requiring approval) in multiple build runs.
We have Azure an azure devops YAML pipeline with multi stage and approvers. I noticed that running different build versions of the same pipeline uses the same work directory on the build server.
How does this not cause corruption of content, for example if the pipeline runs simultaneously for different build versions?
For example what if the newer pipeline run checks out source code while the other run is building and creating artifacts for its own version? I have checked the current path for two concurrent builds and it is the same.
What will happen if you run two commits in the same agent:
Here is my example of multi-stage pipeline:
pool: Default
stages:
- stage: A
jobs:
- job: A
steps:
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(Build.SourcesDirectory)'
artifact: 'drop'
publishLocation: 'pipeline'
- stage: B
jobs:
- deployment: DeployWeb
displayName: deploy Web App
pool: Default
workspace:
clean: all
environment: 'env'
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: CopyFiles#2
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: '**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
I added a approve check in the environment. My running order is stage A(commit1)->stage A(commit2)->stage B(commit1)->stage B(commit2) .
stage A(commit1):
This job will checkout source code of commit1 and publish files in Sources Directory of commit1.
stage A(commit2):
This job will checkout source code of commit2 and publish files in Sources Directory of commit2.
stage B(commit1):
It is a deployment job and will not checkout resource by default.
The deployment job will download the artifact of commit1 as expected.
If I don't clean the workspace, it will continue to use the source code of commit2. This may cause some issues.
If I add a checkout step in this stage. It will checkout the source of commit1.
So you can add checkout step and clean workspace to the deployment jobs. Nondeployment jobs automatically check out source code and it will use the correct source.

Cypress Integration with DevOps

What I want to achieve:
I have a repository on Azure DevOps which hosts my web application. I wrote a test suite for UI Automation using Cypress. I created a separate repository for my test cases to check if they are working properly or not. I created a pipeline which has the following content:
trigger:
- manual-tests
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
displayName: 'npm install'
- task: Npm#1
inputs:
command: 'custom'
customCommand: 'run test'
continueOnError: true
- task: PublishTestResults#2
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-output-*.xml'
testRunTitle: 'My Test Cases'
I have a trigger set to a branch of the repository in which my UI Automation code is stored. What I want is, to trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this? Can we store our test case files in the application repository and give the path of the test script?
It seems that the UI Automation Repo and Web Application Repo are two separate repos.
To trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this?
The function: "trigger a pipeline from a different repo" is not available now.
This feature is still under development. Multi-repository support for YAML pipelines will be available soon for azure devops service.
Please check the function:"Multi-repository support for YAML pipelines" in Azure DevOps Feature Timeline 2020 Q2. This feature will roll out to everyone by the end of July 2020.
Workaround:
You could try to use the Pipeline triggers.
Here are the steps:
Step1: Create a pipeline with web application repository, then you could set the trigger branch.
Step2: Add the Pipeline trigger in the Yaml file (UI Automation Repo).
For example:
resources:
pipelines:
- pipeline: Name
source: Pipeline name
trigger:
branches:
- releases/*
- master
When you make changes in web application repository, the pipeline with the web application will be triggered.
After running the pipeline , the pipeline with UI Automation repo will be triggered.
Can we store our test case files in the application repository and give the path of the test script?
Of cource. You can do it.
If you want to use the test file in the pipeline (UI Automation repo), you could add the repo resouces in the pipeline.
For example:
resources:
repositories:
- repository: MyAzureReposGitRepository
type: git
name: MyProject/WebapplicationRepo
...
steps:
- checkout: MyAzureReposGitRepository
Note: the repo will be check out to the Agent Source Folder.
Hope this helps.

Azure DevOps run build on branch creation

My pipeline looks like:
trigger:
branches:
include:
- release-*
jobs:
- job: release
condition: contains(variables['Build.SourceBranch'], 'refs/heads/release-')
pool:
vmImage: 'windows-latest'
steps:
- bash: |
echo "RELEASE"
displayName: 'release_task1'
How can I make it executed automatically when new release-.. branch is created?
How can I make it executed automatically when new release-.. branch is created?
This is a limitation of YAML trigger.
If the yaml file is not present in the new create branch, the build will not be triggered.
That is reason why it does not execute automatically when creating a new release ... branch.
To resolve this issue, we need to create the yaml file in the basic branch, like release-basic, then we create a new branch based on the branch release-basic. Now the build will be executed automatically.
Hope this helps.

how to restrict the access on build.yml file from developers in Azure DevOps repository

In Azure DevOps we have created both build and release pipeline using classic way and now we are planning this to convert to yaml file.
But it seems in yaml method, the code can be put only on the root of the repo, where we want to keep the build yaml files in a separate repo, where the developers won't have access.
How can achieve this?
You can use templates, put in the main repo only the minimal yaml that refers to a template with all the steps, the template exits in another repo.
For example, your main repo yaml:
resources:
repositories:
- repository: templates
type: git
name: Contoso/BuildTemplates
jobs:
- template: common.yml#templates # Template reference
In in the repo: Contoso/BuildTemplates put the full yaml:
# Repo: Contoso/BuildTemplates
# File: common.yml
parameters:
vmImage: 'ubuntu 16.04'
jobs:
- job: Build
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
Restrict the access to the second repo (unless the agent pipeline user).
Read here more info about the resources.
I agree that one solution could be the one proposed by #Shayki Abramczyk
but to have standalone *.yml in dedicated repository you can use 'git clone' while using 'Git Credentials' to access the other repository that contains the files you want to build by the pipeline.
If your repository dedicated for *.yml is in the same Azure Devops project then you should not have any problem with the release definition.
Please see example *.yml that works for us as described:
pool:
vmImage: 'your-preferred-image'
variables:
solution: '$(Agent.BuildDirectory)/**/YourSolution.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
urlWithCreds: 'https://YourUser:YourPassword#dev.azure.com/YourOrganization/YourProject/
_git/YourOtherRepository'
steps:
- task: CmdLine#2
inputs:
script: |
git --version
git clone --quiet $(urlWithCreds)
git checkout master
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: 'your build args'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
You don't have to keep the YAML files in the root of the repository; ours are in a dedicated sub-folder:
That's crucial, because it means that we can add a PR policy which restricts who can approve changes to any of the pipeline YAML files.