Running GitHub Actions for Certain Commit Messages | Hacker News Reader

Running GitHub Actions for Certain Commit Messages

ryangjchandler.co.uk

77 pointskiyanwang29 comments

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.

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.

GitHub doesn't support push options, sadly.

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')"

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

Can you elaborate?

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.

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.

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.

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/559ebe708343bb7c2f590c0065d...

Looks nicer than any .yaml file (or Groovy script) I've ever seen.

Embedding one language in another isn't an uncommon pattern.

Regular expressions and SQL in my Python

JavaScript and CSS in my HTML

Sed / Awk / etc in my Bash

Embedding a custom conditional syntax in YAML feels pretty tame in comparison to those.

Except that every tool that uses YAML config files has its own unique language for embedding conditional logic, with enough similarities to be familiar, but enough differences and idiosyncrasies to be frustrating, requiring you to re-read the documentation every time you need to write anything as it's impossible to remember the half-dozen different dialects of "YAML logic". I also encounter this every time I need to write a non-trivial regular expression, I can never remember the differences in regex syntax for sed, ruby, JS, etc. etc.

very good points - i disagree on nuances:

- Python provides a grammar for its implementation of regex (note that some langauges make regexes first-class syntax - perl, JS)

- JS has a defined standard cross-platform cross-browser syntax, ditto CSS (yes i know it's not 100% true)

- sed/awk in bash - i agree - but there's a bigger POSIX standard which defines all of it

the problem with yaml is that it isn't even a language, it's just a way to describe a recursive tree/list data structure. everybody defines their own language pretending to standardize on yaml where in fact the syntax similarities are doing little more than mislead you what product you're creating documents for.

What benefit is the YAML giving you?

On your examples, one mixes an specialized language into a general one. The general language is much better for most tasks, but once in a while there is a problem that fits the specialized one. But YAML isn't much better than a general language for defining data structures (what config files are), and isn't general in any way.

The workflows were previously defined using HCL (the syntax used in Terraform), which seems like it could have supported some of this better.

Honestly not sure why YAML is used so much. It either has stuff like this hacked in, or some templating structure, or both. Never the same between one CI tool and another, so you're always having to re-learn how to substitute an environment variable, or use some constructs provided by the tool itself.

And for any half-way complex pipeline, this YAML file will be a few thousand lines long, if not more, and basically impossible to follow.

I believe !foo is part of the YAML spec. It's how you define custom tags (contains in this case).

But it's super confusing because ! usually means NOT in any programming context so you would mentally parse that as the message NOT containing "wip" when in reality, the opposite is what happens. CloudFormation does this too and they have "If" defined as a custom function so you end up with !If which is super confusing for a condition where you expect "if condition is true do this else that".

YAML tags precede their value-terms. For a string value, the !tag syntax occurs before the opening quotation mark/heredoc marker of the string. It’s like a Java annotation.

This isn’t a YAML tag; it’s just YAML embedding some opaque text from some random command-language that uses exclamation marks to mean something.

In fact, actually considering the meaning of the action, the ! used here probably is just the regular ol’ boolean NOT operator in most languages: the action has specified that it should trigger only for commits that aren’t tagged as WIPs. (Which is an eminently-sensible condition to provide.)

Good catch, yeah I think you're right about how it's currently implemented with GH actions.

Which makes things even more confusing overall since ! is a thing in YAML when it's not wrapped in quotes.

Suddenly you have all of these tools implementing their idea of custom behavior in different ways.

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.

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-fo...

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?)

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

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

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

Wouldn't this line in your job accomplish that?

    if: "! contains(github.event.head_commit.message, '[skip ci]')"

+1 for [skip ci] convention

I have something similar for PRs but with labels instead.

if: contains(github.event.pull_request.labels.*.name, 'wip')

Very cool. Thanks for sharing!

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

Reply on news.ycombinator.com