I have a CircleCI job that runs some visual snapshot tests, if the tests fail I'd like to show an approval job to let the developer run a second job that will update the snapshot tests and push them to the PR branch.
This is my current config:
jobs:
- visual-tests
- update-visual-tests-approval:
type: approval
requires:
- visual-tests
# Here I'd need something to only show this (and the subsequent step)
# only if the `visual-tests` step failed
- update-visual-tests:
requires:
- update-visual-tests-approval
What are my options?
this will do the trick:
https://support.circleci.com/hc/en-us/articles/360043188514-How-to-Retry-a-Failed-Step-with-when-Attribute-
you will need to apply this change on the update-visual-tests-approval job.
Related
To automate our CI process, I need run the Bitbucket pipelines only when the title not starts with "Draft" or "WIP". Atlassian has only this features https://support.atlassian.com/bitbucket-cloud/docs/use-glob-patterns-on-the-pipelines-yaml-file/.
I tried with the regex ^(?!Draft:|WIP:).+ like this:
pipelines:
pull-requests:
'^(?!Draft:|WIP:).+':
- step:
name: Tests
but the pipeline not start under any circumstances (with or withour Draft:/WIP:). Any suggestions?
Note the PR pattern you define in the pipelines is matched against the source branch, not the PR title. Precisely, I used to feature an empty pipeline for PRs from wip/* branches, e.g.
pipelines:
pull-requests:
wip/*:
- step:
name: Pass
script:
- exit 0
"**":
- step:
name: Tests
# ...
But this workflow requires you to work on wip/* branches and changing their source branch later on. This is somewhat cumbersome and developers just did not opt-in.
This works, though.
I am little confused here regarding PR being triggered against main branch?
All branches:
(I know this will trigger pull request from any branch to any branch)
pipelines:
pull-requests:
'**':
Main branch:
(Does this trigger pull request if created from feature/pe-1234 to main?)
pipelines:
pull-requests:
'main':
I want to know what happens if I mention only main. It is not clear in documentation or may be I didn't get it right
The branch name / glob pattern in the pull-request pipeline definition is the source branch that should trigger that pipeline, not the target branch.
E.g. if you were following git-flow instead of github-flow, it would make sense to override the pipeline run by the PR from main to a release/whatever branch so that it simply passes, or does an integration test, but does not perform the usual tests, linting, coverage and whatnot.
pipelines:
pull-requests:
'**': # triggers if no other specific pipeline was triggered
- parallel:
- step: *linting-step
- step: *testing-step
main: # triggers from main to anywhere else
- step:
name: Pass
script:
- exit 0
If following github-flow, you will probably never make a PR from main to anywhere else, so you can safely skip this definition. Only if you wanted PRs from feature/AAA-NNNN branches to trigger a special pipeline besides the testing workflow, you can write an alternate pipeline like
pipelines:
pull-requests:
'**': # triggers if no other specific pipeline was triggered
- parallel:
- step: *linting-step
- step: *testing-step
feature/*: # triggers from feature/* to anywhere else (including to main)
- parallel:
- step: *linting-step
- step: *testing-step
- step: *maybe-hook-issue-tracker-step # ?
so that the simpler default '**' pipeline will not run. But it will run irrespective of the target branch, usually main but not necessarily.
I am trying to create a base image for my repo that is optionally re-built when branches (merge requests) make changes to dependencies.
Let's say I have this pipeline configuration:
stages:
- Test
- Build
variables:
- image: main
Changes A:
stage: Test
rules:
- if: '$CI_PIPELINE_SOURCE == "push"'
changes:
- path/to/a
script:
- docker build -t a .
- docker push a
- echo 'image=a' > dotenv
artifacts:
reports:
dotenv: dotenv
Build:
stage: Build
image: $image
script:
- echo build from $image
Let's say I push to a new branch and the first commit changes /path/to/a, the docker image is build and pushed, the dotenv is updated and the Build job successfully uses image=a.
Now, let's say I push a new commit to the same branch. However, the new commit does not change /path/to/a so the Changes A job does not run. Now, the Build stage pulls the "wrong" default image=main while I would like it to still pull image=a since it builds on top of the previous commit.
Any ideas on how to deal with this?
Is there a way to make rules.changes refer to origin/main?
Any other ideas on how to achieve what I am trying to do?
Is there a way to make rules.changes refer to origin/main?
Yes, there is, since GitLab 15.3 (August 2022):
Improved behavior of CI/CD changes with new branches
Improved behavior of CI/CD changes with new branches
Configuring CI/CD jobs to run on pipelines when certain files are changed by using rules: changes is very useful with merge request pipelines.
It compares the source and target branches to see what has changed, and adds jobs as needed.
Unfortunately, changes does not work well with branch pipelines.
For example, if the pipeline runs for a new branch, changes has nothing to compare to and always returns true, so jobs might run unexpectedly.
In this release we’re adding compare_to to rules:changes for both jobs and workflow:rules, to improve the behavior in branch pipelines.
You can now configure your jobs to check for changes between the new branch and the defined comparison branch.
Jobs that use rules:changes:compare will work the way you expect, comparing against the branch you define.
This is useful for monorepos, where many independent jobs could be configured to run based on which component in the repo is being worked on.
See Documentation and Issue.
You can use it only as part of a job, and it must be combined with rules:changes:paths.
Example:
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
paths:
- Dockerfile
compare_to: 'refs/heads/branch1'
In this example, the docker build job is only included when the Dockerfile has changed relative to refs/heads/branch1 and the pipeline source is a merge request event.
There is a project setting, which defines how your MR pipelines are setup. This is only working for Merge requests and can be found in Settings -> Merge Requests under the section Merge options
each commit individually - nothing checked
this means, each commit is treated on its own, and changes checks are done against the triggering commit on it's own
Enabled merged results pipeline
This will merge your MR with the target branch before running the CI Jobs. This also will evaluate all your changes, and take a look at all of them within the MR and not commit wise.
Merge trains
This is a whole different chapter, and for this usecase not relevant. But for completeness i have to mention it see https://gitlab.com/help/ci/pipelines/merge_trains.md
What you are looking for is Option 2 - Merged pipeline results. but as i said, this will only work in Merge Request pipelines and not general pipelines. So you would also need to adapt your rules to something like:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes:
- path/to/a
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
I'm iterating on adding database migrations to a project. For the first step, I've made a repository that runs migrations. Now I need to make it so these migrations run against the stage/prod environment. I do not want this to happen on every commit. Does circle ci provide a way to have a button that I can click on to run a job?
I think ideally I'd have 2 buttons. One for running migrations on stage, one for running them on prod. Is this possible?
There is a manual approval process for workflows.
https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval
workflows:
version: 2
build-test-and-approval-deploy:
jobs:
- build
- test1:
requires:
- build
- test2:
requires:
- test1
- hold:
type: approval
requires:
- test2
- deploy:
requires:
- hold
It's pretty limited. You can't use it to start a build.
I am able to generate build trigger url and able to call build operation via Gitlab Web hook.
But the build operation is calling in each commit irrespective of any branch. But I want to trigger build operation for a specific branch commit. Means want to execute build only if any code pushed to a specific branch.
In Gitlab yaml you can specify each job to trigger on certain branches or excluding branches
https://docs.gitlab.com/ee/ci/yaml/#only-and-except
job_name:
script:
- rake spec
- coverage
stage: test
only:
- master
tags:
- ruby
- postgres
allow_failure: true
The above yaml would only execute on master