search

Ibotta / sopstool

SOPS multi-file wrapper
Apache License 2.0
38 stars 4 forks source link

Remove installer scripts in favor of popular or upstream install methods #47

Open physik932 opened 2 years ago

physik932 commented 2 years ago

Current Behavior

Currently, we recommend installing sopstool via the install.sh script. This installs sops first before installing sopstool. I believe we should instead ask the user to install sops themselves. Other popular wrapper tools like terragrunt or saml2aws do this to simplify management of their tool. I propose we:

  1. Remove the install scripts (install.sh, sopsinstall.sh, sopstoolinstall.sh).
  2. Adjust Travis by downloading (via curl?) a copy of sops 3.7.2 or later directly from the release during the build process.
  3. Adjust the Dockerfile to do the same when we build the image.
  4. Ask the user to install sops as a dependency.

While the scripts themselves aren't a ton of maintenance, it'll just be less the maintain. I'm stuck between hard coding 3.7.2 into Travis or the Dockerfile, or just saying "install sops" and worrying about compatibility ourselves though.

onyxraven commented 1 year ago

turns out the sops download still really benefits from having a script to get the current tag, since that value is also in the artifact filenames. Plus, the format for different platforms is not exactly consistent. In https://github.com/Ibotta/sopstool/pull/58 I have edited that file to be a little more targeted and added some features.

As for sopstoolinstall and install.sh, I do kind of agree - and in that PR mentioned above, moved those lower in the README. I'm ok with potentially dropping those though. IMO our releases are pretty straightforward to acquire. The install script is just nice because it does automatically solve a couple things like sha256 validation and platform selection.