4 ms·

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.
  • simonw 6y ago
    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.
    • toomanybeersies 6y ago
      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.
    • baq 6y ago
      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.
    • marcosdumay 6y ago
      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.
  • ljm 6y ago
    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.
  • nickjj 6y ago
    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".
    • derefr 6y ago
      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.)
      • nickjj 6y ago
        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.