Establish a release workflow for docker images

[larsks]

On the team check-in today, @knikolla expressed a preference for using commit hashes from the main branch as image tags rather than using branch names (to ensure that a deployment continues to use the same image unless it is explicitly changed). This becomes slightly problematic when the same repository houses both the Docker image sources and the openshift deployment manifests.

Kristi suggested an alternative approach using semantic versioning and named tags. There are a number of ways to automate this process; we would like to collect some examples of existing workflows so we can pick one that works well for our projects.

We can collect pointers to good example repositories (and generally discuss the topic of automated release workflows) here in this issue.

[knikolla]

CCI-MOC/ops-docs#22

[larsks]

@knikolla is this the sort of workflow you envisioned? https://github.com/cci-moc/image-workflow-example

[knikolla]

I'm assuming you meant 'sort of workflow', yes. Nice touch on also tagging vX and vX.Y on a new vX.Y.Z release!

[larsks]

Great, then let's discuss some details. :)

That workflow is triggered by pushing a tag, which is simple, but has some disadvantages -- primarily, it requires direct commit access to the repository, and bypasses any existing review process.

In some of my non-image repositories, I do things effectively "in reverse": a commit to a specific file triggers a release workflow, which then extracts the release version from the repository and generates a release.

I like this model, but I haven't tried adapting it to a container image (where we often want per-commit images as well as release images).

[knikolla]

As discussed in backlog grooming, for now, I think requiring push access to creating releases sounds like a good compromise in keeping things simple.

[larsks]

I think this can be closed.

[larsks]

I think this can be closed.