I'm trying to setup Azure Pipelines for a CI setup and I'm using the YAML syntax to get started. However, I was wondering if it is possible to script the flow at "runtime"? Like you can do in Jenkins script: spawn builds etc.
Depending on the commit I want to have a vastly different flow.
This is because I currently have a mono-repo setup with Conan libraries and I want to rebuild the libraries that are necessary depending on the commit, thus the build-flow is not the same for each commit. I want to spawn jobs so I can take advantage of parallel building on several agents.
For your issue ,do you refer to trigger builds based on specified commits? If so, you can trigger builds by adding tag trigger in yaml. You can create tags on the commits. If the tag created meets the trigger condition of the tag trigger in yaml , then the build will be triggered.
trigger:
tags:
include:
- v2.*
Related
I have 1 question regarding Gitlab pipeline triggering. We have multiple gitlab projects which trigger 1 common project. They are doing It separately. The idea is to trigger this project only when subprojects are finished. Is there are any way to do It better than create script which checks pipeline status via API? Because didn't find any out-of-the box solution for this
You can use the trigger:strategy. As per the docs:
Use trigger:strategy to force the trigger job to wait for the downstream pipeline to complete before it is marked as success.
So say you have build and test stages, and you want the trigger job in the build stage to succeed before moving on to the test stage, you could do something like this: =
downstream-build:
stage: build
trigger:
include: path/to/child-pipeline.yml
strategy: depend
I would like to switch from my jenkins jobs to gitlab pipelines entirely.
However, some jobs are never executed as the result of a pipeline.
I would like to be able to trigger these jobs/tasks manually (e.g. by pressing a button or curl).
These manual jobs are intended to perform some source code modifications (such as dependency updates, creating tickets for external rollouts, ...) and create a MR as a result (which is then covered by the normal ci pipelines).
Unfortunately, I haven't found a way to trigger these.
There is the trigger API, that allows to run the pipeliens for a certain branch, but I would like to trigger a pipeline only by name.
I explicitly don't want to rerun the default pipelines on these triggers.
I also considered using environments/deployments, but these tasks lack a real lifecycle and I don't wish to repurpose those for my needs.
TLDR: How do I trigger a job/pipeline by name?
update-dependencies:
only:
- triggers
script:
- update-dependencies.sh
You can use:
when: manual
Example:
update-dependencies:
script:
- update-dependencies.sh
when: manual
How it looks:
I have a great experience of pipeline creating automation (in case of huge amount of repos).
For example, a project has 20 similar repos with Java app (like a microservice) and a pipeline for each of them is differing only by repo url (and a few more minor attributes). The CI/CD process for each of them is the same.
So, we can create a separated devops-repo with declaration configuration for our services. Also we can create a single pipeline which will pull the devops repo and create all needed pipelines for each repo in the configuration (this operation is going to be executed only once in the beginning and in case if we want to change the devops-configuration)
I have implemented that using Jenkins. Now, I am going to do so using GitLab CI. But I can't get how is it possible.
Is it possible to create a pipeline from another one (dynamically)?
Any suggestions?
You can use include and put the generic pipeline in your devops repo.
In your java repos you can include the devops pipeline and set the variables which are specific for the respective java repo.
So the pipeline for your java repos can be as short as this:
include:
- project: 'your-group/devops-repository'
file: '.generic-ci.yml'
variables:
FOO: bar
I am using Azure DevOps and I have a single build pipeline with a number of steps including PublishBuildArtifacts defined in the azure-pipelines.yml file.
I have pointed the same pipeline for the Build Validation (Validate code by pre-merging and building pull request changes.) from the master branch's build policies option. However, for this PR build run, I don't to run certain tasks like PublishBuildArtifacts.
How can I achieve this? I can think of one way which is to create a separate pipeline for PR and also a separate azure-pipelines-pr.yml file and not adding those tasks in that file. But this feels like an approach with redundancy to me. Is there any better way to achieve this?
You can add a custom condition for the publish artifacts step:
and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
Now the step will run only when the build reason is not pull request.
I'm working on a solution that has a yaml build pipeline that does the following
>restore
>build
>test
>publish test
>publish test coverage
>publish source code
And I want to implement a policy in a branch that does the following: whenever a developer creates a pull request to develop branch, that action triggers a build to ensure that the code the developer is trying to merge to develop builds and passes all tests
My question is: as a best practice, should I reuse the build pipeline that I already have, or should I create a new pipeline for that specific job?
Hi Rodrigo you can use the same pipeline as long as you don't have some specific requirements. You can make use of conditions or stages in pipeline yaml to make it robust reuse.
for more information
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema