6 ms·

Our generation shuddered in terror when we were asked to translate a spreadsheet to code while the spreadsheet continued to evolve. This generation will shudde

Our generation shuddered in terror when we were asked to translate a spreadsheet to code while the spreadsheet continued to evolve. This generation will shudder when they are asked to bring discipline to deployments built from github actions.

adastra22 2y ago
What is undisciplined about this?
- TheDong 2y ago
  yaml is roughly as disciplined as malbolge. Writing any meaningful amount of logic or configuration in yaml will inevitably lead to the future super-sentient yaml-based AI torturing you for all eternity for having taken any part in cursing it to a yaml-based existence. The thought-experiment of "Roko's typed configuration language" is hopefully enough for you to realize how this blog post needs to be deleted from the internet for our own safety.
  - adastra22 2y ago
    I literally have no idea what you are talking about. Declarative languages are great for specifying these sorts of things.
    - TheDong 2y ago
      > Declarative languages are great for specifying these sorts of things Yes, good declarative languages are. I'm a happy nix user. I like dhall. cel is a cool experiment. jsonnet has its place. I stan XML. A language with byzantine type rules, like 'on: yes' parses the same as "true: true", but only in some languages (like ruby's built-in yaml parser for example), but not others, and only with some settings, is not it chief. It isn't even one language, since most yaml parsers only have like 90% coverage of the spec, and it's a different percent, so the same yaml document often won't be parsed the same even by two libraries in the same programming language. It's really like 20 subtly incompatbile languages that are all called "yaml". It is indefensible in any context. Github actions should have been in starlark, xml, or even lisp or lua.
rogerrogerr 2y ago
As someone currently working to move a large enterprise to GH Actions (not quite, but “yaml-based pipelines tied to git”) - what would discipline look like? If you can describe it, I can probably make it happen at my org.
- TheDong 2y ago
  I'll give a shot at some guiding principals: 1. Do not use yaml. All github action logic should be written in a language that compiles to yaml, for example dhall (https://dhall-lang.org/ https://dhall-lang.org/). Yaml is an awful language for programmers, and it's a worse language for non-programmers. It's good for no one. 2. To the greatest extent possible, do not use any actions which install things. For example, don't use 'actions/setup-node'. Use bazel, nix, direnv, some other tool to setup your environment. That tool can now also be used on your developer's machines to get the same versions of software as CI is using. 3. Actions should be as short and simple as possible. In many cases, they will be as simple as effectively "actions/checkout@v4", "run: ./ci/build.sh", and that's it. Escape from yaml as quickly as possible, put basic logic in bash, and then escape from bash as quickly as possible too into a real langauge. 4. Do not assume that things are sane or secure by default. Ideally you don't accept PRs from untrusted users, but if you do, read all the docs very carefully about what actions can run where, etc. Github actions on untrusted repos are a nightmare footgun.
  - eadmund 2y ago
    > Escape from yaml as quickly as possible, put basic logic in bash, and then escape from bash as quickly as possible too into a real language. This should be your #1 rule. Don’t compile logic to YAML, just write it in a real language and call it as quickly as possible. This way a developer can run it from his workstation.
  - hnbad 2y ago
    I agree with most of the points but I would condense #2 and #3 to "Move most things into scripts". Sometimes it's difficult to avoid complex workflows but generally it's a safer bet to have actual scripts you can re-use and use for other environments than GitHub. It's a bad idea to make yourself dependent entirely on one company's CI system, especially if it's free or an add-on feature. However I'd balk at the suggestion to use Dhall (or any equally niche equivalent) based on a number of factors: 1) If you need this advice, you probably don't know Dhall nor does anyone else who has worked or will work on these files, so everyone has to learn a new language and they'll all be novices at using that language. 2) You're adding an additional dependency that needs to be installed, maintained and supported. You also need to teach everyone who might touch the YAML files about this dependency and how to use it and not to touch the output directly. 3) None of the advice on GitHub Workflows out there will apply directly to the code you have because it is written in YAML so even if Dhall will generate YAML for you, you will need to understand enough YAML to convert it to Dhall correctly. This also introduces a chance for errors because of the friction in translating from the language of the code you read to the language of the code you write. 4) You are relying on the Dhall code to correctly map to the YAML code you want to produce. Especially if you're inexperienced with the language (see above) this means you'll have to double check the output. 5) It's a niche language so it's neither clear that it's the right choice for the project/team nor that it will continue to be useful. This is an extremely high bar considering the effort involved in training everyone to use it and it's not clear at all that the trade-off is worth it outside niche scenarios (e.g. government software that will have to be maintained for decades). It's also likely not to be a transferable skill for most people involved. The point about YAML being bad also becomes less of an issue if you don't have much code in your YAML because you've moved it into scripts.

adastra22 2y ago

What is undisciplined about this?

TheDong 2y ago
yaml is roughly as disciplined as malbolge. Writing any meaningful amount of logic or configuration in yaml will inevitably lead to the future super-sentient yaml-based AI torturing you for all eternity for having taken any part in cursing it to a yaml-based existence. The thought-experiment of "Roko's typed configuration language" is hopefully enough for you to realize how this blog post needs to be deleted from the internet for our own safety.
- adastra22 2y ago
  I literally have no idea what you are talking about. Declarative languages are great for specifying these sorts of things.
  - TheDong 2y ago
    > Declarative languages are great for specifying these sorts of things Yes, good declarative languages are. I'm a happy nix user. I like dhall. cel is a cool experiment. jsonnet has its place. I stan XML. A language with byzantine type rules, like 'on: yes' parses the same as "true: true", but only in some languages (like ruby's built-in yaml parser for example), but not others, and only with some settings, is not it chief. It isn't even one language, since most yaml parsers only have like 90% coverage of the spec, and it's a different percent, so the same yaml document often won't be parsed the same even by two libraries in the same programming language. It's really like 20 subtly incompatbile languages that are all called "yaml". It is indefensible in any context. Github actions should have been in starlark, xml, or even lisp or lua.

rogerrogerr 2y ago

As someone currently working to move a large enterprise to GH Actions (not quite, but “yaml-based pipelines tied to git”) - what would discipline look like? If you can describe it, I can probably make it happen at my org.

TheDong 2y ago
I'll give a shot at some guiding principals: 1. Do not use yaml. All github action logic should be written in a language that compiles to yaml, for example dhall (https://dhall-lang.org/ https://dhall-lang.org/). Yaml is an awful language for programmers, and it's a worse language for non-programmers. It's good for no one. 2. To the greatest extent possible, do not use any actions which install things. For example, don't use 'actions/setup-node'. Use bazel, nix, direnv, some other tool to setup your environment. That tool can now also be used on your developer's machines to get the same versions of software as CI is using. 3. Actions should be as short and simple as possible. In many cases, they will be as simple as effectively "actions/checkout@v4", "run: ./ci/build.sh", and that's it. Escape from yaml as quickly as possible, put basic logic in bash, and then escape from bash as quickly as possible too into a real langauge. 4. Do not assume that things are sane or secure by default. Ideally you don't accept PRs from untrusted users, but if you do, read all the docs very carefully about what actions can run where, etc. Github actions on untrusted repos are a nightmare footgun.
- eadmund 2y ago
  > Escape from yaml as quickly as possible, put basic logic in bash, and then escape from bash as quickly as possible too into a real language. This should be your #1 rule. Don’t compile logic to YAML, just write it in a real language and call it as quickly as possible. This way a developer can run it from his workstation.
- hnbad 2y ago
  I agree with most of the points but I would condense #2 and #3 to "Move most things into scripts". Sometimes it's difficult to avoid complex workflows but generally it's a safer bet to have actual scripts you can re-use and use for other environments than GitHub. It's a bad idea to make yourself dependent entirely on one company's CI system, especially if it's free or an add-on feature. However I'd balk at the suggestion to use Dhall (or any equally niche equivalent) based on a number of factors: 1) If you need this advice, you probably don't know Dhall nor does anyone else who has worked or will work on these files, so everyone has to learn a new language and they'll all be novices at using that language. 2) You're adding an additional dependency that needs to be installed, maintained and supported. You also need to teach everyone who might touch the YAML files about this dependency and how to use it and not to touch the output directly. 3) None of the advice on GitHub Workflows out there will apply directly to the code you have because it is written in YAML so even if Dhall will generate YAML for you, you will need to understand enough YAML to convert it to Dhall correctly. This also introduces a chance for errors because of the friction in translating from the language of the code you read to the language of the code you write. 4) You are relying on the Dhall code to correctly map to the YAML code you want to produce. Especially if you're inexperienced with the language (see above) this means you'll have to double check the output. 5) It's a niche language so it's neither clear that it's the right choice for the project/team nor that it will continue to be useful. This is an extremely high bar considering the effort involved in training everyone to use it and it's not clear at all that the trade-off is worth it outside niche scenarios (e.g. government software that will have to be maintained for decades). It's also likely not to be a transferable skill for most people involved. The point about YAML being bad also becomes less of an issue if you don't have much code in your YAML because you've moved it into scripts.