gruntwork-io
Define an optional alias so you know which function came from which module.
A typical gruntwork-installer configuration in circle.yml looks like this:
...
- curl -Ls https://raw.githubusercontent.com/gruntwork-io/gruntwork-installer/master/bootstrap-gruntwork-installer.sh | bash /dev/stdin --version "v0.0.14"
- gruntwork-install --module-name "gruntwork-module-circleci-helpers" --repo "https://github.com/gruntwork-io/module-ci" --tag "v0.3.8"
- gruntwork-install --binary-name "docs-generator" --repo "https://github.com/gruntwork-io/module-ci" --tag "v0.3.8"
...
test:
override:
- run-go-tests --path test
The question here is where did that run-go-tests function come from? it'd be nice to answer this systematically. For example, imagine this revised circle.yml:
...
- gruntwork-install --alias "cci" --module-name "gruntwork-module-circleci-helpers" --repo "https://github.com/gruntwork-io/module-ci" --tag "v0.3.8"
...
test:
override:
- cci.run-go-tests --path test
Now it's clear exactly where this came from.
For users browsing the OS, perhaps include a cci.help function that explains which gruntwork-installer command was used to install this.
You know, I think there is a better way to solve this: symlinks.
Instead of copying binaries into /usr/local/bin, we should clone the module into some standard location (e.g. /opt/gruntwork-modules) and create a symlink (e.g. /usr/local/bin/run-go-tests -> /opt/gruntwork-modules/module-ci/modules/run-go-tests/bin/run-go-tests).
The big advantage here is that you see where the binary came from with a simple ls and the docs and versioning info are all retained. The only disadvantage is you don't see where the module came from solely from reading a circle.yml file. But that's generally true of all binaries. When you run git or terraform or go, they are all just symlinks to something, and the name of the app doesn't tell you what.
Funny, your solution doesn't solve my original problem, as you point out, but its elegance makes up for that, and if you're really stuck, you can always run the build environment and SSH in. This seems like a solid approach.