Add workflow to build and publish images (DO THIS after 1240)

[wesley-dean-flexion]

@jpmckinney This PR has a GitHub Action to build an publish a Docker image. If it's merged, it should be merged after #1240 (it depends on the Dockerfile to build it).

What happens first

If this PR is merged before #1240, it'll fail because #1240 has the Dockerfile that describes how to build the image. No Dockerfile == failed build.

If this PR is merged without doing any of the below configuration, it'll fail straight away because it'll look to build /Dockerfile when, in #1240, the Dockerfile lives at /docker/Dockerfile. So, the CONTEXT secret / variable will need to be set (see below). No CONTEXT == failed build.

Secrets and Variables

A couple of secrets will need to be set for this to work:

• CONTEXT will need to be set to docker
• GHCR_USERNAME will need to be set to something, possibly jpmckinney
• GHCR_PAT will need to be set to a Personal Access Token scoped to the wireservice/csvkit repo; it should have repo:status, read:packages, write:packages, and delete:packages permissions
• ghcr_image should probably be set to something like wireservice/csvkit so it's published under the wireservice organization rather than the jpmckinney user account

I hear you say, "but Wes! Why not use environment variables instead?! Sure, that would work just fine. The primary distinction between environment variables and secrets are that secrets are typically redacted in log outputs and are made less visible to folks who have administrative access to the repository. So, if you use all secrets, it'll work just fine.. if you just use a secret for the PAT and environment variables for the rest, that's fine, too.. better safe than sorry

Another question may be, "why delete:packages?" That's a good question. Off the top of my head, I don't know if the write:packages scope allows sufficient permission to overwrite a tagged image. For example, version v2.0.0 is pushed (yay!), the workflow will add v2.0.0 and v2.0 and v2 to the image. Cool. What happens when v2.0.1 is released? It would add tags for v2.0.1 and v2.0 and v2 and I don't happen to know off the top of my shiny head if that requires just write or if delete is required as well.

By default, the image's visibility / access control is set to private; to make it accessible by the public, it'll need to be set to public (docs)

Notes on the build action

The action itself (.github/workflows/publish.yml) has about 100 lines of notes, instructions, etc. that describe how to use and configure it. The TL;DR is that it can publish images to a bunch of places on a variety of platforms (architectures) and those behaviors can be configured through the use of environment variables (or secrets). The environment variables and secrets mentioned above are defined there, too.

GitHub Documentation

Action Secrets: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions
Action Environment Variables: https://docs.github.com/en/actions/learn-github-actions/variables
OATH / PAT Scopes: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes
Publishing to GHCR: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
GHCR access control / visibility: https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility

[jpmckinney]

I'm going to merge a super simple version first.

[coveralls]

coverage: 90.281% (-0.1%) from 90.398%
when pulling 934c239 on wesley-dean-flexion:build_publish_container
into 95a7668 on wireservice:master.

[coveralls]

coverage: 90.281% (-0.1%) from 90.398%
when pulling 934c239 on wesley-dean-flexion:build_publish_container
into 95a7668 on wireservice:master.