5 ms·

Running GitHub Actions for Certain Commit Messages

77 points by kiyanwang 6y ago

throw03172019 6y ago
Very cool. Thanks for sharing!
Joe8Bit 6y ago
It’s a shame GitHub Actions don’t support “[skip ci]” in commit messages, as it seems be the convention similar tools have coalesced around
- TooCreative 6y ago
  Wouldn't this line in your job accomplish that? if: "! contains(github.event.head_commit.message, '[skip ci]')"
- chrisweekly 6y ago
  +1 for [skip ci] convention
baq 6y ago
i'd like to hear who can reasonably defend the "yaml" here, i mean it isn't even trying: jobs: format: runs-on: ubuntu-latest if: "! contains(github.event.head_commit.message, 'wip')"
- tester34 6y ago
  You mean that we're going 2 decades back with the difference that XML based programming is replcaed with YAML? Java people must have ptsd flashbacks
- kerng 6y ago
  Can you elaborate?
  - baq 6y ago
    i kinda hoped it's obvious, but ok. this part if: "! contains(github.event.head_commit.message, 'wip')" is technically yaml, but in truth it's a completely different language with completely different grammar embedded in a yaml string. if pure yaml structure isn't good enough to fulfill use cases of the product, what's the point of using it? you now have a yaml parser and a whatever-this-is parser that needs to be invoked... sometimes, according to some yaml schema? why not create a proper grammar for the whole thing instead of only for a subset? as is, you have two problems: yaml and your custom language - i'd rather have one problem.
    - momothereal 6y ago
      The yaml config is perfectly suited for small/toy projects, which is probably what GitHub intended. Even in larger projects I've never had to use the scripting language. On the other end, we now use Jenkins (the newer version), so every job is a huge Groovy script pretending to be a config file. Much steeper learning curve for anything simple. Pick your poison.
      - baq 6y ago
        i'm in an apparent minority that thinks configuration shouldn't be turing-complete :) but then, to counter my own point, 'configuration' is not as easy to define as i'd like.
      - deleted 6y ago
        [deleted]
      - toomanybeersies 6y ago
        I feel like ruby (or a DSL written in ruby) would be the ideal language for writing CI pipeline "configurations". You'd end up with config files that are actually readable (even to non-rubyists), with a shallow learning curve, but still easily extensible. Here's a 5 minute mockup: https://gist.github.com/gkampjes/559ebe708343bb7c2f590c0065d943a9 https://gist.github.com/gkampjes/559ebe708343bb7c2f590c0065d... Looks nicer than any .yaml file (or Groovy script) I've ever seen.
- derefr 6y ago
  Less of a mess if you use a YAML block literal (basically a heredoc): jobs: format: runs-on: ubuntu-latest if: | ! contains(github.event.head_commit.message, ‘wip’) Other systems that output YAML (e.g. Kubernetes) always emit block literals for embedded user-supplied strings, reserving inline string literals for the cases where the string isn’t expected to need quoting — e.g. string-serialized enum option-values; symbol/atom/keyword-typed values; and sometimes URLs.
Intrepidd 6y ago
Would it trigger for some commit message like "wipe out xxx"? If yes I guess using something like [ci-skip] is safer
anandchowdhary 6y ago
We use the [fast] flag in comments when we want to skip all tests and CI checks and deploy quickly in case of emergency bug fixes: https://koj.co/en-ch/blog/fast-github-actions-deployments-for-emergencies/ https://koj.co/en-ch/blog/fast-github-actions-deployments-fo...
mcintyre1994 6y ago
Does Github actions expose Git push options? One of the nice things Gitlab CI does is skip the CI if you do `git push -o ci.skip` so you don't have to mess with commit messages. It also supports the commit message `[ci skip]` or `[skip ci]` convention, but I find the push option nicer.
- ljm 6y ago
  I never knew about that feature, but that's a pretty cool use-case. The sheer breadth of things git is able to do is quite astounding.
- oweiler 6y ago
  GitHub doesn't support push options, sadly.
thrownaway954 6y ago
i honestly though this was common knowledge from seeing all the [ciskip] commits in projects. was i missing something?
gabythenerd 6y ago
I have something similar for PRs but with labels instead. if: contains(github.event.pull_request.labels.*.name, 'wip')
asdfman123 6y ago
Why not just make feature branches and merge into the branch that auto-builds? Or only push upstream when you're ready to compile? I guess this applies to solo developers who mainly work out of master and like to compulsively push upstream to save their work. (Or am I wrong?)
- xapata 6y ago
  I agree with you. I'm a fan of the branch early and often policy. You have to be good about pruning though.

77 points by kiyanwang 6y ago

throw03172019 6y ago

Very cool. Thanks for sharing!

It’s a shame GitHub Actions don’t support “[skip ci]” in commit messages, as it seems be the convention similar tools have coalesced around

TooCreative 6y ago
Wouldn't this line in your job accomplish that? if: "! contains(github.event.head_commit.message, '[skip ci]')"
chrisweekly 6y ago
+1 for [skip ci] convention

baq 6y ago

i'd like to hear who can reasonably defend the "yaml" here, i mean it isn't even trying: jobs: format: runs-on: ubuntu-latest if: "! contains(github.event.head_commit.message, 'wip')"

tester34 6y ago
You mean that we're going 2 decades back with the difference that XML based programming is replcaed with YAML? Java people must have ptsd flashbacks
kerng 6y ago
Can you elaborate?
- baq 6y ago
  i kinda hoped it's obvious, but ok. this part if: "! contains(github.event.head_commit.message, 'wip')" is technically yaml, but in truth it's a completely different language with completely different grammar embedded in a yaml string. if pure yaml structure isn't good enough to fulfill use cases of the product, what's the point of using it? you now have a yaml parser and a whatever-this-is parser that needs to be invoked... sometimes, according to some yaml schema? why not create a proper grammar for the whole thing instead of only for a subset? as is, you have two problems: yaml and your custom language - i'd rather have one problem.
  - momothereal 6y ago
    The yaml config is perfectly suited for small/toy projects, which is probably what GitHub intended. Even in larger projects I've never had to use the scripting language. On the other end, we now use Jenkins (the newer version), so every job is a huge Groovy script pretending to be a config file. Much steeper learning curve for anything simple. Pick your poison.
    - baq 6y ago
      i'm in an apparent minority that thinks configuration shouldn't be turing-complete :) but then, to counter my own point, 'configuration' is not as easy to define as i'd like.
    - deleted 6y ago
      [deleted]
    - toomanybeersies 6y ago
      I feel like ruby (or a DSL written in ruby) would be the ideal language for writing CI pipeline "configurations". You'd end up with config files that are actually readable (even to non-rubyists), with a shallow learning curve, but still easily extensible. Here's a 5 minute mockup: https://gist.github.com/gkampjes/559ebe708343bb7c2f590c0065d943a9 https://gist.github.com/gkampjes/559ebe708343bb7c2f590c0065d... Looks nicer than any .yaml file (or Groovy script) I've ever seen.
derefr 6y ago
Less of a mess if you use a YAML block literal (basically a heredoc): jobs: format: runs-on: ubuntu-latest if: | ! contains(github.event.head_commit.message, ‘wip’) Other systems that output YAML (e.g. Kubernetes) always emit block literals for embedded user-supplied strings, reserving inline string literals for the cases where the string isn’t expected to need quoting — e.g. string-serialized enum option-values; symbol/atom/keyword-typed values; and sometimes URLs.

Intrepidd 6y ago

Would it trigger for some commit message like "wipe out xxx"? If yes I guess using something like [ci-skip] is safer

anandchowdhary 6y ago

We use the [fast] flag in comments when we want to skip all tests and CI checks and deploy quickly in case of emergency bug fixes: https://koj.co/en-ch/blog/fast-github-actions-deployments-for-emergencies/ https://koj.co/en-ch/blog/fast-github-actions-deployments-fo...

mcintyre1994 6y ago

Does Github actions expose Git push options? One of the nice things Gitlab CI does is skip the CI if you do `git push -o ci.skip` so you don't have to mess with commit messages. It also supports the commit message `[ci skip]` or `[skip ci]` convention, but I find the push option nicer.

ljm 6y ago
I never knew about that feature, but that's a pretty cool use-case. The sheer breadth of things git is able to do is quite astounding.
oweiler 6y ago
GitHub doesn't support push options, sadly.

thrownaway954 6y ago

i honestly though this was common knowledge from seeing all the [ciskip] commits in projects. was i missing something?

gabythenerd 6y ago

I have something similar for PRs but with labels instead. if: contains(github.event.pull_request.labels.*.name, 'wip')

asdfman123 6y ago

Why not just make feature branches and merge into the branch that auto-builds? Or only push upstream when you're ready to compile? I guess this applies to solo developers who mainly work out of master and like to compulsively push upstream to save their work. (Or am I wrong?)

xapata 6y ago
I agree with you. I'm a fan of the branch early and often policy. You have to be good about pruning though.