3 ms·

Not to deride this (too much), but the 'robustness' of deployments with shell scripts is tempting bait. Things are until they aren't, 'nobody rides for free' -

Not to deride this (too much), but the 'robustness' of deployments with shell scripts is tempting bait. Things are until they aren't, 'nobody rides for free' - decide what you're willing to pay. Example: this interprets the output of 'ls'. Reliability is dependent on good quoting/never introducing a project with spaces Ansible is a nice middle ground, personally. I write the state that differs, use a library of scripting.

joshka 3y ago
Or a project name that overlaps an init.d script they'd prefer to have kept It also doesn't fail immediately if many of the commands fail (instead blindly moves on to the next statement). Consider using bash and these options: https://github.com/kvz/bash3boilerplate/blob/main/main.sh#L18-L27 https://github.com/kvz/bash3boilerplate/blob/main/main.sh#L1... for most scripts.
cess11 3y ago
Putting SAVEIFS=$IFS IFS=$(echo -en "\n\b") or something similar at the top of the script might not come across as comparable to adopting Ansible to some people.
- bravetraveler 3y ago
  I knew giving specific examples would lead this way, that's not my point. This case has been handled. Others? There isn't anything really insightful here. Someone pleased with a script has not yet grown beyond the needs of it. Yay. The more portable/maintainable version of this is a playbook or whatever. Someone wrote and tested a better version of whatever Work Unit as a module. Wheel enthusiast is pleased with their finely polished, but not particularly traveled, wheel. It's great, but they're commodities and not seeing much. I would have done the same thing with 'ansible-pull' and zero code, in even less time/effort... but I also already know Ansible and bash. Configuration management tools are excellent at managing applications and configs. Who knew. Something else to suggest: systemd timers. At a glance info for scheduling of the job, instead of inferred from logs that may or may not have been recorded. You can also then actually declare your deployment needs networking. Eyeroll.jpg. This is great because the bar is so low. They'll generate a ton of useless logs if they lose networking, as-is. Long enough and the disk will fill: this is trying every minute.
  - cess11 3y ago
    OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration. When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.
    - bravetraveler 3y ago
      Let's take a step back from names for a second - I feel we're getting a little distracted by that. My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post! I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar. If the goal is to minimize surprises, the amount of effort put into something, etc - is it not best to follow the beaten path? They're to be commended for making a solution that works well for them, and echoing the KISS methodology, I just don't think a shell script is it. Anecdotes are funny, I guess. It's worked well for them - but I'm here because similar things have gone terribly for me. Small decisions can have big influence
      - cess11 3y ago
        Pretty sure bash and Perl and C (and make and autotools and probably something I'm forgetting) are the beaten path in this context, i.e. software building and deployment on Unix. Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines. In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.
- riddley 3y ago
  Pro tip: unsetting IFS has the same effect as saving and restoring the old value.
  - cess11 3y ago
    Ah, nice, thanks. I've been cargo-culting this for ages without thinking much about it.
rkta 3y ago
Parsing ls is an anti-pattern, but the author says it works for years - we all do mistakes and as long as it works you don't notice. And it's an easy fix: - for project in $(ls go-cicd); do + cd go-cicd || exit 1; for project in \*; do
- hawski 3y ago
  I would suggest not to mess with the current working directory and instead do something like this: for project in go-cicd/*; do project="${project#*/}"
  - bravetraveler 3y ago
    Indeed, thank you for mentioning that - I was going to suggest similar. That said, if you do (ie: scratch files, things outside of control, whatever), consider the directory stack: https://www.gnu.org/software/bash/manual/html_node/Directory-Stack-Builtins.html https://www.gnu.org/software/bash/manual/html_node/Directory... Using 'pushd' and 'popd' can save your fingers/brain from getting lost in context.
    - arp242 3y ago
      I like using subshells for this: ( cd dir for f in ./*; [..] ) There's a few scenarios where this won't work (mainly if you want to set a variable from the "outer scope"), but 99% of the time it works nicely.
      - bravetraveler 3y ago
        Ah, that's a nice/neat thought - thank you for sharing! Makes total sense, temporary/disposable shell for such things

joshka 3y ago

Or a project name that overlaps an init.d script they'd prefer to have kept It also doesn't fail immediately if many of the commands fail (instead blindly moves on to the next statement). Consider using bash and these options: https://github.com/kvz/bash3boilerplate/blob/main/main.sh#L18-L27 https://github.com/kvz/bash3boilerplate/blob/main/main.sh#L1... for most scripts.

cess11 3y ago

Putting SAVEIFS=$IFS IFS=$(echo -en "\n\b") or something similar at the top of the script might not come across as comparable to adopting Ansible to some people.

bravetraveler 3y ago
I knew giving specific examples would lead this way, that's not my point. This case has been handled. Others? There isn't anything really insightful here. Someone pleased with a script has not yet grown beyond the needs of it. Yay. The more portable/maintainable version of this is a playbook or whatever. Someone wrote and tested a better version of whatever Work Unit as a module. Wheel enthusiast is pleased with their finely polished, but not particularly traveled, wheel. It's great, but they're commodities and not seeing much. I would have done the same thing with 'ansible-pull' and zero code, in even less time/effort... but I also already know Ansible and bash. Configuration management tools are excellent at managing applications and configs. Who knew. Something else to suggest: systemd timers. At a glance info for scheduling of the job, instead of inferred from logs that may or may not have been recorded. You can also then actually declare your deployment needs networking. Eyeroll.jpg. This is great because the bar is so low. They'll generate a ton of useless logs if they lose networking, as-is. Long enough and the disk will fill: this is trying every minute.
- cess11 3y ago
  OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration. When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.
  - bravetraveler 3y ago
    Let's take a step back from names for a second - I feel we're getting a little distracted by that. My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post! I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar. If the goal is to minimize surprises, the amount of effort put into something, etc - is it not best to follow the beaten path? They're to be commended for making a solution that works well for them, and echoing the KISS methodology, I just don't think a shell script is it. Anecdotes are funny, I guess. It's worked well for them - but I'm here because similar things have gone terribly for me. Small decisions can have big influence
    - cess11 3y ago
      Pretty sure bash and Perl and C (and make and autotools and probably something I'm forgetting) are the beaten path in this context, i.e. software building and deployment on Unix. Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines. In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.
riddley 3y ago
Pro tip: unsetting IFS has the same effect as saving and restoring the old value.
- cess11 3y ago
  Ah, nice, thanks. I've been cargo-culting this for ages without thinking much about it.

rkta 3y ago

Parsing ls is an anti-pattern, but the author says it works for years - we all do mistakes and as long as it works you don't notice. And it's an easy fix: - for project in $(ls go-cicd); do + cd go-cicd || exit 1; for project in \*; do

hawski 3y ago
I would suggest not to mess with the current working directory and instead do something like this: for project in go-cicd/*; do project="${project#*/}"
- bravetraveler 3y ago
  Indeed, thank you for mentioning that - I was going to suggest similar. That said, if you do (ie: scratch files, things outside of control, whatever), consider the directory stack: https://www.gnu.org/software/bash/manual/html_node/Directory-Stack-Builtins.html https://www.gnu.org/software/bash/manual/html_node/Directory... Using 'pushd' and 'popd' can save your fingers/brain from getting lost in context.
  - arp242 3y ago
    I like using subshells for this: ( cd dir for f in ./*; [..] ) There's a few scenarios where this won't work (mainly if you want to set a variable from the "outer scope"), but 99% of the time it works nicely.
    - bravetraveler 3y ago
      Ah, that's a nice/neat thought - thank you for sharing! Makes total sense, temporary/disposable shell for such things