Our CI setup is currently looking like this on GitHub:
Usually, first check is finishing much sooner than second check. It can succeed or fail. Is it possible (and if so - how) to "break early" and terminate remaining actions as soon as some action fails?
You can do this easily but only within a single workflow. If you have multiple workflows.
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
fail-fast: true
Related
I have a CI pipeline setup for release and debug builds:
trigger:
batch: true
branches:
include:
- "master"
- "main"
- "feature/*"
- "hotfix/*"
strategy:
matrix:
'Release':
buildConfiguration: 'Release'
'Debug':
buildConfiguration: 'Debug'
Both are ran regardless of errors:
I want to change this behaviour so that when one job fails the other job also stops - saving me build minutes.
Is this possible?
We do not have any built-in method can easily automatically cancel all in-progress jobs if any matrix job fails.
As a workaround, you can try the following method:
Add a script task (such as PowerShell or Bash) as the last step of the matrix job.
Set the script task runs when any of the previous tasks is failed (condition: failed()).
On the script task, set the script to execute the REST API "Builds - Update Build" to cancel current build.
With this way, when any task in the job is failed, the script task will run and execute the REST API to cancel the whole build.
Of course, if you really want a built-in easy method can be used (for example, add the option jobs.job.strategy.fail-fast), I recommend that you can report a feature request on Developer Community. That will make it possible for you to interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.
I am using GitHub a
ctions to manage my CI and the following events trigger my workflow:
on:
pull_request:
branches: main
push:
branches: main
I observed the following "problem":
When I create a PR, the CI is run. If the test passes and I merge it into main, the tests are run again (which I don'
t want in specific cases). How can I setup my workflow such that the CI is not triggered when merging a PR, where the CI already passed for the PR?
Thanks in advance!
You might consider an if conditional in your case:
jobs.<job_id>.if
You can use the jobs.<job_id>.if conditional to prevent a job from running unless a condition is met. You can use any supported context and expression to create a conditional.
When you use expressions in an if conditional, you may omit the expression syntax (${{ }}) because GitHub automatically evaluates the if conditional as an expression. For more information, see "Expressions".
jobs:
build:
if: github.event.pull_request.merged == false
. . .
That would still trigger the workflow, but it can skip the jobs in the workflow.
Alternatives exist in this thread, which deals with the opposite requirements ("Trigger workflow only on pull request merge"): it can be adapted to do what you need (not trigger a workflow, or at least do the same job twice, on PR merge)
I'm trying to set a github branch protection rule based on the success or failure of a github actions workflow.
You can see the workflow here:
https://github.com/apostrophecms/apostrophe/blob/main/.github/workflows/main.yml
The workflow passes, and I even have a working badge for it, but I am unable to set a branch protection rule requiring that it pass as a status check.
I can set a branch protection rule based on any one of the individual builds in the matrix, but I don't want to set all of them individually and keep track of that as my matrix rule changes.
As you can see from the screenshots, I am unable to pick "build", the name of the job (although I can pick any of the sub-builds), and I am also unable to pick "tests", the name of the workflow as a whole (it does not change if I use an uppercase t).
What am I missing? Thanks for your help!
Screenshot one: I can pick a sub-build but not the entire build job.
Screenshot two: I can't pick the name of the overall "Tests" workflow at all.
There's a trick to add one step to the workflow to collect all jobs from the matrix to one check:
tests:
runs-on: ubuntu-latest
needs: build
if: always()
steps:
- name: All tests ok
if: ${{ !(contains(needs.*.result, 'failure')) }}
run: exit 0
- name: Some tests failed
if: ${{ contains(needs.*.result, 'failure') }}
run: exit 1
if: always() is obligatory to collect failed tasks, otherwise PR will never get a proper status check. Also, this is an additional step for you to pay (if you use paid plans).
In this case, you have a single job with a matrix. That means you'll end with 9 possibilities (3 node options × 3 MongoDB options). Each of those is considered a separate status check and can be enabled or disabled as mandatory individually. This is so that you can add new options without making them mandatory up front.
If you want every one of those jobs to pass, then you need to choose every one of the 9 jobs and mark them as required.
I want to cancel the previous run when a new run is executed.
So, referring to the https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency document, I added the concurrency keyword.
Below is my sample code.
name: test
on:
push:
branches:
- feature/**
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
jobs:
~~~
However, when executing the action, an error saying "The key 'concurrency' is not allowed" is thrown and it does not work. The examples on google are no different from my sample code. What is the cause?
(If the concurrency keyword is removed, the action works normally.)
Tried the code you provided and it worked for me with no issue. Not sure what the problem is on your side. Are you running this on a GitHub-provided runner or are you self-hosting one? Can't gauge that since you job description is missing. Also do you have a link to the repository maybe?
Something to try would be to add the concurrency key on the job level instead of the global level. Maybe that changes things for you
I can't see anyone talking about what I'm looking to do. I'm currently running a pipeline on a branch merge within the bitbucket area.
branches:
staging:
- step:
name: Clone
script:
- echo "Clone all the things!"
What I want to do is when a branch gets merged into master, trigger an event that will enable the schedule to run for the next day.
If there are no changes I don't want anything to run, however, if there are I want the schedule to kick in and work.
I've read through the Pipeline triggers:
https://support.atlassian.com/bitbucket-cloud/docs/pipeline-triggers/
But I can't see anywhere that would allow me to do it. Has anyone done this sort of thing? Is it possible, or am I limited by bitbucket itself?
Never done this, but there's an API for creating schedules. I think you would need to determine the date and specify the single cron task, e.g. March 30, 2022 at midnight:
0 0 30 3 * 2022
However year is an extension, not a standard CRON field; "at" is an alternative that may be accessible (but also not standard). It all depends on what Bitbucket allows for CRON schedule, so I think this is not a conclusive answer (still needs info on how to setup the schedule).
Here is the docs
https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/pipelines_config/schedules/