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.521000.bestmunity/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.

[meadowsys]

yoinked this out of that community post (https://github.521000.bestmunity/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]

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

[christophehurpeau]

In case you missed it : https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

[neverendingqs]

Curious: wouldn't support for a workflow if condition be a more generic solution that also solves this problem?

[TingluoHuang]

@neverendingqs a workflow if will still create a workflow run, and there is no workflow run get created with [skip ci]

[neverendingqs]

@neverendingqs a workflow if will still create a workflow run, and there is no workflow run get created with [skip ci]

I think you may be thinking of the jobs if. Workflow if doesn't exist today, but should prevent workflow runs if it did.

[TingluoHuang]

I understand we don't have workflow if today. 😄
I am saying base on the current architecture of GitHub actions, all if condition gets evaluate after the workflow run is queued to our workflow execution engine.

[Rochet2]

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

Emphasis mine. The bolded part sounded like exactly what I was trying to make a case against. 😨
However, when I actually tested the functionality it is working as I had hoped. 😌

I pushed the following commits in a single push, the topmost commit being HEAD, and the build was not skipped:

• dummy edit to readme
• try to [skip ci]

[timharris777]

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

Emphasis mine. The bolded part sounded like exactly what I was trying to make a case against. 😨
However, when I actually tested the functionality it is working as I had hoped. 😌

I pushed the following commits in a single push, the topmost commit being HEAD, and the build was not skipped:

• dummy edit to readme
• try to [skip ci]

You might want to open an issue as a bug. They closed this feature request already.

[rmacklin]

I came here after seeing https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci and wanting to express a desire for this to be configurable per workflow file.

Essentially, it'd be nice for [skip ci] to automatically skip some workflows but still run others that we consider mandatory.

Regarding these comments:

Curious: wouldn't support for a workflow if condition be a more generic solution that also solves this problem?

base on the current architecture of GitHub actions, all if condition gets evaluate after the workflow run is queued to our workflow execution engine.

That makes sense. But what if there was a more limited option that didn't need everything a regular if expression can include? It seems like to "support [skip ci] out of the box with github actions", somewhere in the workflow triggering process there is new logic akin to this conditional (pseudocode): if commit_message.includes?('[skip ci]')

What if workflow definitions could include a boolean field to opt into/out of this behavior? In which case that logic could become: if workflow_definition.opted_into_skip_ci? && commit_message.includes?('[skip ci]')

That'd be good enough for opting into the [skip ci] automatic skipping behavior on a per workflow basis.

...But what'd be really neat is if we could take it one step further, like in @timharris777's initial example. This would be a bit more complex, but much more flexible:

name: foo workflow
on: pull_request
skip_if_commit_message_includes:
  - [skip foo workflow]

name: bar workflow
on: pull_request
skip_if_commit_message_includes:
  - [skip bar workflow]
  - [skip ci]

which would require the logic changing to something like

list = workflow_definition.skip_if_commit_message_includes
if list.present? && list.any? { |flag| commit_message.includes?(flag) }

That still doesn't seem too far off from the logic that currently has to run - it's nowhere near as dynamic as a general if condition, but it would still offer a lot more flexibility.

(Perhaps the skip_if_commit_message_includes list could be truncated if it exceeds a certain length to avoid that any? loop taking too long if someone tried to abuse it.)

[tjenkinson]

This seems like a nice change but it is a breaking one and I think should be opt-in. On our repo we auto merge dependabot prs when the checks have run, and we include 'skip ci' to prevent Netlify running.

Now it's impossible to merge dependabot prs because the required status checks never run.

Please could this be reverted and made an option somewhere?

[abitrolly]

@tjenkinson wouldn't [skip netlify] be more appropriate in your case?

[tjenkinson]

If that works, yes. Will give it a go :)

[tjenkinson]

@abitrolly thanks it seems that works! Can't find it mentioned in any Netlify docs though.

[abitrolly]

@tjenkinson I would still raise an issue with Netlify. Just to make sure it is an officially supported feature.

[Rasbats]

[skip ci] not working for my PR.

[smac89]

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

Emphasis mine. The bolded part sounded like exactly what I was trying to make a case against. fearful
However, when I actually tested the functionality it is working as I had hoped. relieved
I pushed the following commits in a single push, the topmost commit being HEAD, and the build was not skipped:

• dummy edit to readme
• try to [skip ci]

You might want to open an issue as a bug. They closed this feature request already.

I don't think that's a bug. The HEAD commit obviously does not contain any elements required to skip, therefore since both were pushed at once, actions will not be skipped

[kerryj89]

I guess I misunderstood this part because it still initiated the action:

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

If any commit message in your push [...]

I'm guessing I'll have to remember adding [skip ci] again into GitHub.com's pull request commit message (from the individual PR page) or am I misunderstanding? BitBucket didn't need this extra step.

[Rochet2]

@kerryj89

BitBucket didn't need this extra step.

Havent used bitbucket for CI, but sounds like a bug as their faq does not say it would do that. Or maybe you did squash or similar that included the skip ci in the commit message from previous commits. I couldnt find a proper documentation with a quick search about how it should work there, other than the faq.

I'm guessing I'll have to remember adding [skip ci] again into GitHub.com's pull request commit message

Yes. The head commit of a push/pull request needs the [skip ci]. See here for the current docs: https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs

am I misunderstanding?

The blogpost is wrong. I posted my tests earlier in this thread.
I also notified github about it over a year ago, but it seems its lost in backlog.
Here is a ticket I made and here are the important parts of my email exchange with support:

The team definitely can see how the message is confusing. Colloquially it should be:

If the commit message in your push contains any of the following strings: [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

The same idea applies to the HEAD commit of a pull request.

We've followed up with the team in charge of modifying the blog and let them know if this suggestion. With that being said, I'm not sure if they will be changing it, but they are definitely aware and have added it to their backlog of issues.

In the end the documentation has been rewritten multiple times and no longer seems to have the issue. It no longer resides in the same place even.
However, the blogpost is still unchanged which saddens me. 😢

[yvele]

Is there a way to disable this new [skip ci] behavior?

In my pipeline, I don't see any legitimate use case for disabling CI through a commit message. Some developers on my team use [skip ci] because they consider the commit "not that important," which undermines the semantic meaning that commit messages should carry. In our workflow, [skip ci] is counterproductive and goes against the intended purpose of commits in reflecting changes for the changelog and project lifecycle.