Skip to content

Dockerhub Repository Integration

Gregory Lemieux edited this page Sep 17, 2020 · 6 revisions

This github repo uses webhooks to initiate automatic image builds ("autobuilds") for the NGEET dockerhub organization repos.

Autobuilds and Tagging

Dockerhub autobuilds have the capability to be started ("triggered ") by either the update to a specified branch or by an update to a tag. Given that this github repo contains multiple dockerfiles that map to different image repos on dockerhub, the autobuild triggering mechanism should be specific enough to only trigger one repo build at a time. As such the follow methodology was devised

Tag/Trigger methodology

Dockerhub image autobuilds triggering off of tags can use regular expressions to match specific tag formats. This allows us to define for each dockerhub repo a specific tag format that corresponds to a particular dockerfile update on this github repo. This idea was inspired by the CTSM groups use of multiple tags. For example, we setup the gcc650 baseos dockerhub image repo to only build when it sees that a gcc650-v.x.x.x tag has been updated on the github repository. Thus all pull requests to the github master branch should be tagged after the fact with the specific tag format to enable a dockerhub image build as necessary. See the Tag and Release Protocol page for a guide on creating tags and the current list of tag prefixes.

Autobuilds and Pull Requests

Since the dockerhub autobuilds are triggered only by tagging, a pull request can include any update to the master branch without worrying about triggering a build (i.e. updating the README or other supplemental files). That said, it is recommended that pull requests to master should be relatively narrow in scope so as to only incorporate a minimum number of autobuilds to reduce the amount of tags that need to be pushed. This is particularly important since some build updates may have an order dependence requiring that a baseos tag be updated prior to a downstream hlm-fates build.