Ghcr push workflow

[rajeswari1301]

What this does:

• Builds on every push to master and every PR (to catch broken Dockerfiles early)

• Only pushes to GHCR on tagged releases - same pattern as the Python packages

• Tags the image with the version number and commit SHA so we can trace and roll back any build

• All third party actions are pinned to commit SHAs instead of floating tags
  References:

• https://github.com/docker/login-action

• https://github.com/docker/metadata-action

• https://github.com/docker/build-push-action

• https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

[rajeswari1301]

Also, wanted to add caching to the workflow- was thinking about it since the Docassemble docker file is pretty heavy(lots of python packages, NLTK downlaods, pandoc, etc). Without caching every build starts from scratch which could take some time.

So the idea is to use inline registry cache since we're already pushing to GHCR anyway - cache gets stored in the image itself and reused on the next build. Just the two lines to add:
cache-from: type=registry,ref=ghcr.io/${{ github.repository }}:latest
cache-to: type=inline

References I looked at:

• https://docs.docker.com/build/ci/github-actions/cache/ - Docker docs on caching strategies
• https://github.com/docker/build-push-action#inputs ( cache-from and cache-to inputs)
• https://www.blacksmith.sh/blog/cache-is-king-a-guide-for-docker-layer-caching-in-github-actions - tradeoffs between inline and registry cache

Not a blocker for the PR, just thought it was worth adding.

[BryceStevenWilley]

Looks good to me! I don't think we'll need to run on pull requests (mostly because most won't be targeting master).

I'll make that change and maybe retarget the PR to a new branch. There will have to be a lot of copying of commits around.