This is a very minor issue, but in a CI workflow like GH Actions if you install from the GH releases you could end up doing something like this:
- name: Install svu
run:
curl -kL https://github.com/caarlos0/svu/releases/download/v3.2.3/svu_3.2.3_linux_amd64.tar.gz | tar zx && \
mv svu /usr/local/bin/svu && \
chmod +x /usr/local/bin/svu
...And if you have previously checked out your repo, unbeknownst to you, you have now overwritten your repo's README.md with svu's README locally. If this action commits and pushes code or publishes via NPM or some other package manager which loads the README, svu instructions are now disseminated to those locations.
Obviously even in that method ☝️ this can be easily corrected, so the easiest option to address this would be to create a note or example of CI usage. But you could also consider not including the README/LICENSE in the release tarball and possibly embedding the completion scripts into the binary?
This is a very minor issue, but in a CI workflow like GH Actions if you install from the GH releases you could end up doing something like this:
And if you have previously checked out your repo, unbeknownst to you, you have now overwritten your repo's README.md with svu's README locally. If this action commits and pushes code or publishes via NPM or some other package manager which loads the README, svu instructions are now disseminated to those locations.
Obviously even in that method ☝️ this can be easily corrected, so the easiest option to address this would be to create a note or example of CI usage. But you could also consider not including the README/LICENSE in the release tarball and possibly embedding the completion scripts into the binary?