Runner: Support [skip ci] out of box with github actions

[timharris777]

Pretty much every other ci/cd solution will skip running a workflow/pipeline if [skip_ci] is in the commit text.

Currently the hack for this is to add an if statement to jobs with something like "! contains(toJSON(github.event.commits.*.message), '[skip-ci]')". However, this still runs the workflow, just not any jobs with the condition.

Please provide an out of box way for this to happen. One solution would be something like paths-ignore:

on:
  push:
    commit-ignore:
    - [skip ci]
    - [ci skip]
    - ***NO_CI***

@eseay

[missedone]

some caveat of edge case is, one push could have multi commits, what's the expected behavior when some commits has [skip ci] while the last commit doesn't have

[eseay]

@missedone I'd say that so long as its behavior is documented, then either way would work. The way that CircleCI handles it is to make the build skip for all pushed commits in a batch, as documented here.

[missedone]

@eseay , good to know.

[missedone]

i'm thinking can this be extended to PR title, Ex. if the title contains [skip ci] etc.

[eseay]

@missedone Yea that could be a cool addition as well!

[mockitoguy]

Really surprised this feature is not available out of the box. Please add.

[kungfuchicken]

+1

[mstachniuk]

I created an action for that: https://github.com/marketplace/actions/ci-skip-action
Happy using and waiting for the feedback!

[Rochet2]

A github community post related to this issue can be found here:
https://github.community/t/github-actions-does-not-respect-skip-ci/17325
I think it contains some very good points and some solutions.

what's the expected behavior when some commits has [skip ci] while the last commit doesn't have

I think the CI should behave the same as how it acts when pushing several commits.
That is, CI is only run for latest commit so it should also check the CI tag only for the last commit in a batch.
If every commit would be built by the CI then every commit would be evaluated separately for the skip CI tag.

The simplicity of checking only the latest commit for a skip CI tag is nice and leaves less corner cases.
Many more complex approaches can be done when needed through scripts by a project that needs them.

I'd say that so long as its behavior is documented, then either way would work.

Its harder to make it work for everyone and in all cases if you have to consider the other commits also.
For example think of a merge of two repositories.
You are making a huge merge with potentially hundreds of commits that likely contain a skip CI tag somewhere.
You are not going to want to really skip CI on that one, right?

I have previously found that a clever feature (documented or not) to build the latest commit without the skip CI tag was harmful.
https://travis-ci.community/t/ci-skip-in-merge-commit-builds-previous-commit/1695
The issue was that for example in merges the commits may not even be from the same branch or repository, which results in failures in the build as code can be missing. As a result the skip CI tag was useless.
The merges were tested and then pushed by the CI, so the CI afterwards was unnecessary, however using the skip CI tag resulted in CI failure every time due to merged commits being built and code missing from the repo.

[autumnblazey]

yoinked this out of that community post (https://github.community/t/github-actions-does-not-respect-skip-ci/17325)

name: my CI github action

on:
  push:
    branches:
      - master

jobs:
  build:
    if: "!contains(github.event.head_commit.message, 'skip ci')"
    runs-on: ubuntu-latest

then if "skip ci" is in the commit message, it will skip it (haven't tested this myself). However, still a pain to include this in every repo that needs it, and having it on by default would be nice (not many commit messages have "skip ci" in them without intending to skip ci :P)

[pllim]

Doesn't work anymore. head_commit isn't in the event no more. Not sure why.

[pllim]

if: "!contains(github.event.head_commit.message, 'skip ci')" only works if github.event_name is push, not pull_request, which does not help at all when a repository allows pull requests from contributor's forks, which is quite common in OSS.

[abitrolly]

This is now the most upvoted issue.

https://github.com/actions/runner/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

[karamkaramkaram]

W