jeffersonlab/container-workflows repository overview

⁠container-workflows

GitHub Action container workflows

⁠Reusable workflows

⁠How to use

This project uses it's own workflows in order to test them (the Dockerfile is just a demo/example). Copy and paste one or more of the following files into your project .github/workflows directory and update parameters accordingly:

Both workflows require the DOCKER_USERNAME and DOCKER_TOKEN secrets be defined in the calling project repo on GitHub. The JLab organization license doesn't support org-level secrets at the moment. The gh-release workflow is triggered by bumping the VERSION file.

⁠Version Notes

⁠v1

• The docker-publish workflow assumes there is a demo compose version specified in the file compose.override.yaml, so this file must exist in the caller repo. The version is automatically bumped on release
• yaml files end with .yml
• Default build-arg of CUSTOM_CRT_URL=http://pki.jlab.org/JLabCA.crt⁠

⁠v2

• compose.override.yaml is not required, and you should use latest tag inside if you do use it.
• yaml files end with .yaml
• No default build-args are provided - you should embed defaults inside your Dockerfile

⁠Workflow Updates

Workflows are versioned in semver just as with regular software, however, the GitHub Action workflows convention is to reference a major version number such that backwards compatible minor and patch updates are received automatically. This means a separate major tag such as v1 must be moved after each release. To move a major tag after a release execute (v1 shown):

git tag -f v1
git push --tags -f

⁠See Also

• Other workflows⁠
• Projects using this⁠