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.
Related
I have an azure devops package feed which was working fine for my purposes, until recently a hard drive failure disrupted operations. Suddenly I found myself unable to push any packages without running into a 401 response. I was able to get it to work eventually after modifying a nuget.config file as described in the answer to this question, but given that this entire process was fairly convoluted, it seems like there should be a much more straight-forward way to set this up when needed. So that in the case I ever need to do this again in the future, and so that I don't have to rely on getting lucky with stack overflow answers, what is the best, most straight-forward method for setting up publishing to azure devops package feeds?
nuget.config is the most commonly used authentication method for push packages to feed. There are two ways to push packages to feed, I think you may need another.
Pipeline push should be a easy way to achieve your requirement.
trigger:
- none
pool:
vmImage: 'windows-latest'
steps:
- checkout: self
persistCredentials: true #This step will do the auth.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration Debug'
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'byPrereleaseNumber'
majorVersion: '1'
minorVersion: '0'
patchVersion: '2'
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'xxx/xxx'
You just need to 'click' the feed you want push to and then change the step of YAML like the above.
After that, give the permission to pipeline:
Finally, run the pipeline to push artifact to feed:
Each step of this method is very clearly and each time you want to push artifact, you just need to change several settings is ok(Version, Repo that the pipeline based on, artifact name). Create once, use for a long time.
Additional:
How to change the repo that the pipeline based on:
Repository Structure on my side:
Everything of push artifacts:
Publish Nuget packages(NuGet.exe)
Publish Nuget packages(dotnet)
Publish NuGet packages with Azure Pipelines (YAML/Classic)
Azure static web apps(preview) currently only works with a github account, and as a company policy we have to use Azure for repos and everything else (pipelines, releases, etc..) We are going to use the static web app just for viewing a simple angular website however all the source code must remain in the azure devops repo.
Is is possible to create a private github account and upload to it only the compiled angular files to make use of the static web app? for example we already have a pipeline to compile and deploy the angular website to an Azure web app service, can this pipeline be modified to publish the same files to the github account? and if so how?
You can do it in Azure Devops. Try put this YML in Azure DevOps Pipeline
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
name: 'yourApplicationName'
steps:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
displayName: 'Install Node.js'
- script: |
npm install -g #angular/cli
npm install
displayName: 'npm install'
workingDirectory: '$(Build.SourcesDirectory)/yourApplicationName'
- task: AzureStaticWebApp#0
inputs:
app_location: "/yourApplicationName"
api_location: "api"
app_build_command: $(build_command)
output_location: "dist/yourApplicationName"
env:
azure_static_web_apps_api_token: $(deployment_token)
You can put build_command and deployment_token in the variables
Azure SWA is only available for code in Github at the moment.
However, you can get something pretty close with Azure App Service. Microsoft even has a couple blog posts about how to configure Azure App Service, Azure Repos and Azure Pipelines together.
You can deploy a React Static Web Apps from Azure using Pipelines as follows:
name: Azure Static Web Apps CI/CD
#
# Trigger off of changes in master or another branch(s)
#
trigger:
branches:
include:
- TestBranch
jobs:
- job: build_and_deploy_job
displayName: Build and Deploy Test Web App
condition: or(eq(variables['Build.Reason'], 'Manual'),or(eq(variables['Build.Reason'],'PullRequest'),eq(variables['Build.Reason'], 'IndividualCI')))
pool:
vmImage: ubuntu-latest
variables:
- group: <Name of your Static Web App Resource Group>
steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp#0
inputs:
azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_TOKEN_#####)
# Details at https://aka.ms/swaworkflowconfig
app_location: "/" # App source code path
api_location: "" # Api source code path - optional
output_location: "build" # Built app content directory - optional
app_build_command: 'chmod 755 scripts/*.sh;./scripts/WebAppBuild.sh prod'
You will first need to set up a connection in Azure->Settings->Pipelines->Service Connections. Use the Pipeline wizard to set up all the initial YML.
The key for me was to run my own build in WebAppBuild.sh which basically runs "npm run build". My repo has a scripts folder. The job/task performed the rest of the install
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.
I have a following structure:
Test-A and Test-B projects created on Azure Devops. Test-A project's CI build pipeline will produce an artifact.
Test-B's pipeline uses the artifact produced by Test-A's CI pipeline in its build. I am able to download the build artifact of Test-A project and use it.
The problem I am facing here is I am unable to do a CI automatic trigger with project Test-A dependency in project Test-B i.e when ever I make changes and push the changes on to Test-A github repo or whenever I do a new build on Test-A I want the build for Test-B to start automatically.
I have read the documentation on Azure devops but they are not working.
Link for pipeline trigger
Link for pipeline multi-trigger
Below is my .yml file.
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
resources:
pipelines:
- pipeline: JustAName
project: Test-A
source: Test-A_CI
branch: master
trigger:
branches:
include:
- master
repositories:
- repository: justAnotherName
type: github
name: myGitRepo
endpoint: myGitServiceConnection
trigger:
branches:
include:
- master
steps:
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'specific'
project: 'hashValue or Test-A'
definition: '1'
specificBuildWithTriggering: true
buildVersionToDownload: 'latest'
targetPath: '$(Agent.BuildDirectory)'
I am not sure where I am doing wrong or if it is a permission issue. I checked the logs to find any reference with the resources part in the yml but I had no luck.
Can someone suggest what is the best way to check what is the problem and resolve the issue.
Build completion option is disable in classic editor
The build completion option in the pipeline classic editor is limited to the pipelines within the same project. So it won't work for your scenario(the triggering pipeline and triggered pipeline reside in different project) even if it is enabled.
For issue build completion option is disabled. You can report this issue here. Click report a problem and select Azure Devops.
Resources pipeline trigger doesnot work properly sometimes. This similar issue has submitted to Microsoft by some other users. You can follow and vote on these cases or create a new one. Build Completion Triggers not working, Pipeline trigger not working as expressed in documentation
You can follow the workaround which using task TriggerPipeline given by #Hugh. You can also add a powershell task to call the rest api to queue another build pipeline. You can check this thread for example scripts
For your issue , there is a custom task in the Azure DevOps marketplace: Trigger Azure DevOps pipeline.
With this task you can trigger a build or release pipeline from another pipeline within the same project or organization but also in another project or organization.
To get started a PAT is needed with the appropriate rights to execute pipelines. Give the PAT the following rights depending on your scenario:
Triggering a Build: Build – Read & execute
When you have installed the extension, you can add this task into yaml. In the task setting ,you need to connect to a Azure DevOps Service connection. For detailed configuration, please refer to this.
steps:
- task: TriggerPipeline#1
inputs:
serviceConnection: 'triggerpipeline'
project: 'Test-B'
Pipeline: 'Build'
buildDefinition: 'xxx'
Branch: 'master'
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.