3 ms·

Yup, it seems that shell embedded in YAML is pretty much a pattern now (Github Actions, Gitlab, Kubenetes, Travis CI, sourcehut, etc.) And I think it's growing

by chubot 6y ago

Yup, it seems that shell embedded in YAML is pretty much a pattern now (Github Actions, Gitlab, Kubenetes, Travis CI, sourcehut, etc.) And I think it's growing beyond CI/CD -- that is, Github actions is a more general platform than Travis CI, etc. Good example: https://lobste.rs/s/oeelem/using_github_issues_as_hugo_frontend_with https://lobste.rs/s/oeelem/using_github_issues_as_hugo_front... My pet peeve is that YAML is a terrible syntax for a shell script, i.e. there are if statements in a weird YAML DSL in addition to if statements in shell (which people already complain is hard to remember) People complain about shell syntax, but YAML is even worse. So I would like to make Oil a better language for specifying these "distributed shell scripts": https://news.ycombinator.com/item?id=25343716 https://news.ycombinator.com/item?id=25343716

bredren 6y ago
It is not a very pretty pattern but the value on GA is so high for me these days, I just fight it until I get what I need. I think there are probably very elegant ways to combine yaml and shell scripting, maybe by careful factoring of things into their own actions. I hope so. I will check out oil.
- chubot 6y ago
  Yes, the lobste.rs thread also has that feedback: Github Actions is a tremendously useful platform, but the syntax and tooling sucks! Since JSON is valid YAML, it's possible to generate JSON from an Oil configuration with embedded and parsed shell, rather than using YAML. (Actually there's no problem generating YAML either, but I suppose it's easier to think about.) Example: I changed my own configs to use .yml.in and .yml and it worked on both Travis CI and sourcehut. https://github.com/oilshell/oil/tree/master/.builds https://github.com/oilshell/oil/tree/master/.builds Some brainstorming here on this feature: https://github.com/oilshell/oil/wiki/Config-Dialect https://github.com/oilshell/oil/wiki/Config-Dialect The benefit would be that it would validate your syntax and possibly your schema locally, not remotely. Some services have command line tools, but I'm sure they don't validate your shell, only the configuration. Another benefit is the ability to reuse code and configuration. For example, my .builds/ dir has a fair bit of redundancy in its configuration, and that could be "factored" with a real language. YAML has a limited << reference mechanism that does some of this. I'm looking for feedback on Oil, as well as the YAML + shell replacement idea. I hope that Oil can be a flexible language that will let people write these sorts of front ends for many cloud services, i.e. "distributed shell scripts". And eventually enable portability across clouds too. https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback

by chubot 6y ago

bredren 6y ago

It is not a very pretty pattern but the value on GA is so high for me these days, I just fight it until I get what I need. I think there are probably very elegant ways to combine yaml and shell scripting, maybe by careful factoring of things into their own actions. I hope so. I will check out oil.

chubot 6y ago
Yes, the lobste.rs thread also has that feedback: Github Actions is a tremendously useful platform, but the syntax and tooling sucks! Since JSON is valid YAML, it's possible to generate JSON from an Oil configuration with embedded and parsed shell, rather than using YAML. (Actually there's no problem generating YAML either, but I suppose it's easier to think about.) Example: I changed my own configs to use .yml.in and .yml and it worked on both Travis CI and sourcehut. https://github.com/oilshell/oil/tree/master/.builds https://github.com/oilshell/oil/tree/master/.builds Some brainstorming here on this feature: https://github.com/oilshell/oil/wiki/Config-Dialect https://github.com/oilshell/oil/wiki/Config-Dialect The benefit would be that it would validate your syntax and possibly your schema locally, not remotely. Some services have command line tools, but I'm sure they don't validate your shell, only the configuration. Another benefit is the ability to reuse code and configuration. For example, my .builds/ dir has a fair bit of redundancy in its configuration, and that could be "factored" with a real language. YAML has a limited << reference mechanism that does some of this. I'm looking for feedback on Oil, as well as the YAML + shell replacement idea. I hope that Oil can be a flexible language that will let people write these sorts of front ends for many cloud services, i.e. "distributed shell scripts". And eventually enable portability across clouds too. https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback