I am using TravisCI's Build Stages to separate my job to two stages:
Build and test on multiple environments.
Build and deploy if stage 1 pass.
And I want to Travis to run the jobs on commits to two GitHub branches, master and dev, and pull requests to master and dev. However, I only want to run the stage two when a commit to master happens.
Is there a way to completely ignore stage 2 in commits to branches that are not master, and on pull requests?
This is what my .travis.yml looks like at the time of writing this:
https://github.com/SammyIsra/photostream-react/blob/c354a62c3cc963b345a5c2fb95658c90ddc39d21/.travis.yml
Update:
this seems to not be possible as of yet. However, the TravisCI team may be working on something like that, as of this comment on the Build Stages feedback board. Whenever I learn that it was added as a feature, or that it will definitely not be possible ever, I will change this question.
There doesn't seem to be a way to ignore specific branches when triggering jobs in the build stages section, however it looks like there's a way to only fire your deployments on pushes to master.
In your build stage script section, you could wrap the npm run build command in a quick Bash if statement to test the environment variable which shows what branch you're on:
if [ TRAVIS_BRANCH == "master" ]; then npm run build; fi
Then, in your Surge deploy section, you can restrict the deployment to a particular branch with:
deploy:
...
on: master
And basically the same for the NPM deployment:
deploy:
...
on:
branch: master
Note: I've not tried any of this myself, so it may or may not work in combination with the new build stages functionality.
Related
I have a ADO git repo with a YAML-based build pipeline that builds a docker image, runs some tests using Docker Compose, and then pushes the image and a helm chart to an ACR.
I'd like the have the build/test part run on PRs too. I have created a second pipeline that's just the first half of the normal build, and assigned it as a Build Validation pipeline for a branch.
However, I don't seem to be able to get the triggers right. If I have trigger: none in the test pipeline, it never triggers. If I have branch names, it is also run on merge alongside the normal build pipeline. How is this supposed to work? The docs define all the individual parts, but not really how they are expected to interact!
Am I supposed to have a multistage pipeline and use that somehow for the validation? (it's just 4 Steps in one Job in one Stage currently).
I am hoping to avoid building the same image too many times, or storing untested images anywhere outside the build agent.
I make it work with the following configuration:
In my YAML pipeline, I set the trigger: none.
In branch policies of a branch, I create a build validation with automatic trigger:
Then I create a pull request to that branch, and the pipeline runs automatically:
There are two possible mistakes:
The "Manual" trigger is selected in build validation, so that the pipeline needs to be run manually rather than triggered automatically.
The branch with branch policy set should be the same branch as the target branch of pull request.
I have a multi-stage pipeline, where after successful deploy to QA environment, API tests and E2E tests are run (both of them are in separate repos).
A bug in E2E tests had made them fail, so we fixed it, merged the changes and re-run the E2E stage. The problem is that re-run runs the previous commit (before fixes). The only way we know to run latest commit of E2E tests would be to run all the pipeline again, but it'd take too much time because of long duration of previous stages.
Is there a possibility to re-run latest commit without running the whole multi-stage pipeline?
Is there a possibility to re-run latest commit without running the whole multi-stage pipeline?
Nope. A pipeline run is anchored on the commit which you selected when starting the pipeline. No matter how many times you restart it (or stages of it), it uses the same commit.
//Edit: Actually, depending on your pipeline logic, you could run a new pipeline with only selected stages:
The problem was resolved by adding git pull origin master step at the beginning.
- ${{ if ne(parameters.checkoutRepository, 'self') }}:
- script: git pull origin master
displayName: Update repository
I want to use both CI-triggers and PR build validation in Azure DevOps. The goal is that as long as no PR has been created (and published) for a feature/topic-branch, the CI triggers should ensure that the branch gets built (so that developers get early feedback). I configured the following in the Pipeline (yaml):
trigger:
branches:
include:
- chore/*
- feature/*
- fix/*
- refactor/*
paths:
include:
- frontend/*
...
This works well. I further configured PR build validation under branch policies. The problem is that two builds are triggered now: the CI build and the PR build. Since we often update PRs multiple times to fix issues found during the code review, building everything twice isn't really what we need.
Is there any way to configure that CI builds are only triggered if there's no PR build for the same push?
This is not possible. They are totally separated triggers not aware of each other.
But you can achiever your result in a slightly different way. If you have branch policy configured and you sleect there a build you can set pr: none in you yaml definiton. It will block PR build, leaving CI build as they are. And this CI build will be considered as condition for you branch policy check.
Selecting this checkbox you will get list of builds which you may select as required
My Ci trigger build
PR view:
If I understand the question correctly add:
trigger: none
In your CI pipeline. This will have the PR kick it off via branch policy. Your CD pipeline will be triggered when the merge into master happens.
If you are using the Azure DevOps Repo, then the PR build is controlled by branch policies, but the CI-trigger (in azure-pipeline.yaml) has nothing to do with this branch policy.
So if you want both build validation for PR and the CI build at the same time, then every time you push your changes to update a PR, duplicate pipeline builds would be unavoidable. It is a side-effect.
I'm new to the yaml build config game and as such I do a lot of trial and error. So I want to be able to test run my pipeline and see if it is working as I intended. But I don't want to have to check in the yaml file into my master branch for every incremental change to be able to test run it.
Is it possible to run a pipeline from a separate branch or without checking in code all together?
Thanks!
Agree with Shayki, you can create a test branch based on the master branch. Then create a new pipeline. Switch to the test branch in yaml.
The changes in this yaml will be committed to the test branch.
I am modifying a concourse script I inherited.
We have a pipeline that looks like this:
[1]build - [2]test A - [3]test B - [4]publish - [5]deploy
Our team worked only with the master branch before but now we are using feature branches.
I made a modification to build step to run for every branch - not only master. But I want publish step to run only for the master branch builds.
How can I make step 5 to run only when the step 1 was run for the master branch? Is there a way of doing this on Concourse?
If the same pipeline builds all the branches, then either you are not using the git resource or you are using a modified git resource that supports multiple branches.
I assume that what you call "steps" 1...5 are Concourse jobs.
I can see two options.
Option 1. Simple but dirty/misleading.
At the beginning of steps 4 and 5, check for the git branch. If not master, return success immediately. The pipeline will stay green and the publish and deploy jobs will look like they have ran, while actually they did nothing.
Option 2. Slightly more complicated but the proper way.
Use two pipelines. One pipeline for all branches except master. This pipeline will contain only steps 1 ... 3. The second pipeline will track the master branch and have all the steps 1 ... 5.
The question now is how to manage these 2 pipelines in a DRY fashion (no code duplication, no possibility for the pipelines to drift away one from the other)?
The answer is to use a YAML merge tool like https://github.com/geofffranks/spruce. The README mentions BOSH but it is a completely generic YAML merge tool.
The last part is how to stay DRY and at the same time specify different branches. This can be obtained with https://concourse-ci.org/setting-pipelines.html#pipeline-vars.