After 3 weeks or labouring and using FSS with a fully working system, I dropped it all and went back to Ansible. I don't regret the time spent because I picked up a lot of transferrable skills from command line utilities and bash.
There are simple things like downloading a file which BashBooster gets wrong. If the file already exists, it should not abort, it should resume download or compare file sizes to ensure that the previous download didn't terminate abruptly. Basically, this and other idempotency issues need to be dealt with very carefully. Even simple things like "mkdir -p foo" instead of just "mkdir foo".
Once you get past idempotency you will most likely run into performance issues and then into project velocity.
If you really must use Bash Scripts, I would suggest using them via Ansible's Shell + Command modules. This will allow you to lean on Ansible until your Bash scripts can catch up. It will also give you Ansible's inventory management features.
I haven't used Gentoo for a long time but wasn't part of it's package system a nice little DSL for writing scripts that would "download files, unpack them, install packages, etc".
On a more serious note, you should know how to use bash scripts effectively, but also know their limitations (true idempotence is hard, testing is annoying, error handling is hit or miss, etc.); there's a reason most infrastructure moves towards a higher level of abstraction/convenience like Ansible or Puppet.
[1]: https://github.com/brandonhilkert/fucking_shell_scripts
EDIT: BashBooster says it's developed to be used with Vagrant, whereas f_s_s is stand-alone. So it doesn't quite require nothing.
In the time it took you to type your comment, you could have had a BB account registered, and in the time it takes to reply to my comment, you could have installed your SSH keys and had the same basic workflow set up.
People's unwillingness to explore alternatives for the most superficial of reasons are how monopolies are started and perpetuated.
Some day, Github is going to be acquired or taken over by advertisers or something, life is going to start sucking, and people will put up with it for the same reason they put up with Facebook.
How would you compare this with something like Shunit2[1]?
I can see someone missing some error confirmations by being careless when producing the output or testing things in isolation.
But I can also see how this could be more likely to catch some side effects (stupid example: unclosed terminal escapes) in combined output.
I was looking for a nice testing tool for my bash migration tool[2], and while the `assert` way is well known, I like writing bash because it's bare and requires discipline and yours seems survivalist enough.
[1]: https://code.google.com/p/shunit2/ [2]: https://github.com/zenoamaro/rash
For example: in the same bash interpreter source code. See files using the '.right' extenion [0].
I think it's a flexible approach, compared to using things as shunit, or TAP producers.
The main advantage of using shunit (or TAP producers too), I think is to re-use available tools (at least in the case of TAP producers), and the possible familiarity of new contributors with the syntax.
Personally I avoid test libraries that use traps and eval, and bash code can become so complex, that I thing there is not a single testing library (Written in bash) that could work with all my code base.
As soon as you start using advanced features (shell options, traps, code tracing features, readonly stuff, filedescriptors, etc) most assumptions become wrong.
Anyway, the most hard part of test complex shell programs (specially those related to system administration), is to test functionality.
It's easy (and even not useful) to assert that 'myecho 1' will print '1' and return 0.
But things become hard to test when you want to see if a partition routine works well with +2TB disks, if a netfilter ruleset is resilient to attacks (unknown by the author), if a program is safe to unexpected (by the programmer) input, if a backup restore will not break production...
Fun to see this on hackernews front page. One of my pet projects is just the same, but not being inspired by chef.
For the tests, I'm writing my own xUnit tool [1]. It doesn't use any fancy stuff, runs on set -euf, it's tested by itself and works on every POSIX-like shell that I could find (bash, dash, zsh, (m|pd)ksh, yash, posh, even busybox) and many different versions and OSs.
On the functional side, I've decided that I need to test using virtual machines. The test matrix tool that can spawn and test on them is almost ready [2], it already tests the library itself and exports the matrix configuration to Travis.
Very early stuff though and doesn't even touch problems like partition routines you mentioned, but overall I'm happy with the results, considering everything runs under 70Kb of code.
[1] https://github.com/Mosai/workshop/blob/master/doc/posit.md
[2] https://github.com/Mosai/workshop/blob/master/test/matrix.sh
For simple standing up of a new box though - sure, any of them will do.
Yet all projects are alive yet, so there probably is some difference which makes all tools applicable. So it makes me feel uncomfortable asking this obviously nonsensical question, but: is there some one tool I should chose if I want to get away from the stone age of using bash scripts for provisioning?
https://zwischenzugs.wordpress.com/2014/06/07/phoenix-deploy...
http://ianmiell.github.io/shutit/
https://github.com/ianmiell/shutit
Used extensively within our corp for container builds, but easily repurposed for straightforward shell provisioning. Bash within a build-friendly python framework.
I talk about it more here:
https://www.youtube.com/watch?v=zVUPmmUU3yY
tho slightly out of date.
Some blogging on it here:
