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