Versioning
Part of our quest for keeping workflows stable is proper versioning of the tools. It's important to provide users with the latest and greatest updates to their tools by default but also allow them to revert to a previous version if need be.
You must always tag your image before pushing it in at least one of the following ways:
Versioning Conventions
Git commit short hash
This is the recommended way that should be used for all tools as it's a unique value and you can easily use it to match a container image to its source. If a tool is hosted on a public git repository, it should use this convention by default, preferably in addition to the others listed below. You can add multiple tags to one image using the following command
docker build -t name:tag1 -t name:tag2
GitHub releases
If the tool has an official release cycle, you should follow the same versioning convention it uses. You can use wget
to download the release into the image using the following command
wget https://github.com/author/tool/releases/download/<version>/tool.zip
apt-get
If a tool is available on an apt
repository, use this command to install a specific version
apt-get install tool=<version>
go install
For Go tools hosted on git repositories, use go install
to install a specific version or a specific commit
go install github.com/author/tool@<version OR commit hash>
If this doesn't work, fall back to one of the methods above.
pip
For Python tools hosted on pypi.org
, use pip
to install a specific version
pip install tool==<version>
gem
For Ruby tools hosted on rubygems.org
, use gem
to install a specific version
gem install tool -v <version>
npm
For JavaScript tools hosted on npmjs.com
, use npm
to install a specific version
npm install -g tool@<version>
Old versions
End users can access older versions of the tools through the git history of the tool's corresponding trickest.yaml
file.
Notes
- If a tool has more than one active branch (e.g.
main
anddev
), each branch should be treated as a separate tool. - If a tool has more than one active fork, each one should be treated as a separate tool.
- No new tags should be created unless the code on the original repo (referenced in
source_url
intrickest.yaml
) changes. Updates anywhere else should keep the same tag.
Next up: Parameterizing STDIN/STDOUT