3 ms·

100%. The ci/cd job should be nothing more than a wrapper around the actual logic which is code in your repo. I write a script called `deploy.sh` which is my w

100%. The ci/cd job should be nothing more than a wrapper around the actual logic which is code in your repo. I write a script called `deploy.sh` which is my wrapper for my ci/cd jobs. It takes options and uses those options to find the piece of code to run. The ci/cd job can be parameterized or matrixed. The eventually-run individual jobs have arguments, and those are passed to deploy.sh. Secrets/environment variables are set from the ci/cd system, also parameterized/matrixed (or alternately, a self-hosted runner can provide deploy.sh access to a vault). End result: from my laptop I can run `deploy.sh deploy --env test --modules webserver` to deploy the webserver to test, and the CI/CD job also runs the same job the same way. The only thing I maintain that's CI/CD-specific is the GitHub Action-specific logic of how to get ready to run `deploy.sh`, which I write once and never change. Thus I could use 20 different CI/CD systems, but never have to refactor my actual deployment code, which also always works on my laptop. Vendor lock-in is impossible, thanks to a little abstraction. (If you have ever worked with a team with 1,000 Jenkins jobs and the team has basically decided they can never move off of Jenkins because it would take too much work to rewrite all the jobs, you'll understand why I do it this way)

hardwaresofton 2y ago
Hey if you’ve never heard of it consider using just[0], it’s a better makefile and supports shell scripting explicitly (so at least equivalent in power, though so is Make) [0]: https://github.com/casey/just https://github.com/casey/just
- 0xbadcafebee 2y ago
  Thank you, I have seen it, but I prefer Make.
  - eru 2y ago
    I bet all your targets are .PHONY?
    - derkades 2y ago
      But I can install it on any Linux system from the base repository
      - eru 2y ago
        If all your targets are .PHONY, you might as well just as bash (or your favourite shell) directly. Make targets look suspiciously like functions (or procedures), but they actually aren't.
        hardwaresofton 2y ago
        One of the benefits of just -- it isn't a build system, it's a command runner. Good facilities for arguments, builtins like absolute locations -- there are a ton of benefits (see the README).
        0xbadcafebee 2y ago
        I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue. Here is an example of a "complex" Makefile I use to help manage Helm deployments (https://github.com/peterwwillis/devops-infrastructure/blob/main/make/helm-chart.Makefile https://github.com/peterwwillis/devops-infrastructure/blob/m...). It uses canned recipes, functions (for loops), default targets, it includes targets and variables from other Makefiles, conditionally crafts argument lists, and more. (It's intended to be a "default" Makefile that is overridden by an additional Makefile.inc file) I could absolutely rewrite that in a shell script, but I would need to add a ton of additional code to match the existing functionality. Lines of code (and complexity) correlates to bugs, so fewer lines of code = less bugs, so it's easier to maintain, even considering the Make-specific knowledge required. They say "use the best tool for the job". As far as I've found, for a job like that, Make fits the best. If some day somebody completely re-writes all the functionality of Make in a less-obnoxious way, I'll use that.
        eru 2y ago
        > I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue. They are still phony at heart in this case, even if you don't declare them .PHONY. Make really wants to produce files; if your targets don't produce the files they are named for you are going to run into trouble (or have to be rather careful to avoid the sharp edges). > They say "use the best tool for the job". As far as I've found, for a job like that, Make fits the best. If some day somebody completely re-writes all the functionality of Make in a less-obnoxious way, I'll use that. You could try eg Shake (https://shakebuild.com/ https://shakebuild.com/), but it requires some Haskell.
- chubot 2y ago
  The shell also supports shell scripting! You don't need Just or Make Especially for Github Actions, which is stateless. If you want to reuse computation within their VMs (i.e. not do a fresh build / test / whatever), you can't rely on Just or Make A problem with Make is that it literally shells out, and the syntax collides. For example, the PID in Make is $$$$, because it's $$ in shell, and then you have to escape $ as $$ with Make. I believe Just has similar syntax collisions. It's fine for simple things, but when it gets complex, now you have {{ just vars }} as well as $shell_vars. It's simpler to "just" use shell vars, and to "just" use shell. Shell already has a lot of footguns, and both Just and Make only add to that, because they add their own syntax on top, while also depending on shell.
- OldOneEye 2y ago
  I discovered Just with a similar comment in Hacker News and I want to add my +1. It is so much better to run scripts with Just than it is doing it with Make. And although I frankly tend to prefer using a bash script directly (much as described by the parent commenter), Just is much less terrible than Make. Now the only problem is convincing teams to stop following the Make dogma, because it is so massively ingrained and it has so many probems and weirdnesses that just don't add anything if you just want a command executor. The PHONY stuff, the variable scaping, the every-line-is-a-separate-shell, and just a lot of stuff that don't help at all.
  - 0xbadcafebee 2y ago
    Make has a lot of features that you don't use at first, but do end up using eventually, that Just does not support (because it's trying to be simpler). If you learn it formally (go through the whole HTML manual) it's not hard to use, and you can always refer back to the manual for a forgotten detail.

hardwaresofton 2y ago

Hey if you’ve never heard of it consider using just[0], it’s a better makefile and supports shell scripting explicitly (so at least equivalent in power, though so is Make) [0]: https://github.com/casey/just https://github.com/casey/just

0xbadcafebee 2y ago
Thank you, I have seen it, but I prefer Make.
- eru 2y ago
  I bet all your targets are .PHONY?
  - derkades 2y ago
    But I can install it on any Linux system from the base repository
    - eru 2y ago
      If all your targets are .PHONY, you might as well just as bash (or your favourite shell) directly. Make targets look suspiciously like functions (or procedures), but they actually aren't.
      - hardwaresofton 2y ago
        One of the benefits of just -- it isn't a build system, it's a command runner. Good facilities for arguments, builtins like absolute locations -- there are a ton of benefits (see the README).
      - 0xbadcafebee 2y ago
        I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue. Here is an example of a "complex" Makefile I use to help manage Helm deployments (https://github.com/peterwwillis/devops-infrastructure/blob/main/make/helm-chart.Makefile https://github.com/peterwwillis/devops-infrastructure/blob/m...). It uses canned recipes, functions (for loops), default targets, it includes targets and variables from other Makefiles, conditionally crafts argument lists, and more. (It's intended to be a "default" Makefile that is overridden by an additional Makefile.inc file) I could absolutely rewrite that in a shell script, but I would need to add a ton of additional code to match the existing functionality. Lines of code (and complexity) correlates to bugs, so fewer lines of code = less bugs, so it's easier to maintain, even considering the Make-specific knowledge required. They say "use the best tool for the job". As far as I've found, for a job like that, Make fits the best. If some day somebody completely re-writes all the functionality of Make in a less-obnoxious way, I'll use that.
        eru 2y ago
        > I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue. They are still phony at heart in this case, even if you don't declare them .PHONY. Make really wants to produce files; if your targets don't produce the files they are named for you are going to run into trouble (or have to be rather careful to avoid the sharp edges). > They say "use the best tool for the job". As far as I've found, for a job like that, Make fits the best. If some day somebody completely re-writes all the functionality of Make in a less-obnoxious way, I'll use that. You could try eg Shake (https://shakebuild.com/ https://shakebuild.com/), but it requires some Haskell.
chubot 2y ago
The shell also supports shell scripting! You don't need Just or Make Especially for Github Actions, which is stateless. If you want to reuse computation within their VMs (i.e. not do a fresh build / test / whatever), you can't rely on Just or Make A problem with Make is that it literally shells out, and the syntax collides. For example, the PID in Make is $$$$, because it's $$ in shell, and then you have to escape $ as $$ with Make. I believe Just has similar syntax collisions. It's fine for simple things, but when it gets complex, now you have {{ just vars }} as well as $shell_vars. It's simpler to "just" use shell vars, and to "just" use shell. Shell already has a lot of footguns, and both Just and Make only add to that, because they add their own syntax on top, while also depending on shell.
OldOneEye 2y ago
I discovered Just with a similar comment in Hacker News and I want to add my +1. It is so much better to run scripts with Just than it is doing it with Make. And although I frankly tend to prefer using a bash script directly (much as described by the parent commenter), Just is much less terrible than Make. Now the only problem is convincing teams to stop following the Make dogma, because it is so massively ingrained and it has so many probems and weirdnesses that just don't add anything if you just want a command executor. The PHONY stuff, the variable scaping, the every-line-is-a-separate-shell, and just a lot of stuff that don't help at all.
- 0xbadcafebee 2y ago
  Make has a lot of features that you don't use at first, but do end up using eventually, that Just does not support (because it's trying to be simpler). If you learn it formally (go through the whole HTML manual) it's not hard to use, and you can always refer back to the manual for a forgotten detail.