Setup automatic docker build and publish to docker registry

[lenkan]

This PR adds a step in the workflow to publish the container image to docker hub on push to main

The tags pushed are:

• :main
• :build-<github run id>
• :sha-<short commit sha>

The workflow_dispatch accepts the following options:

• version
• latest (true/false)
• dry run (lets you test the docker build and inspect tags before push)

Some simplifications:

• Remove build-keria and publish-keria from makefile. If we are doing this through actions anyway, I want to remove misleading instructions.
• Moved dockerfile from ./images/keria.dockerfile to ./Dockerfile. This is more common if you have one image that the repository build. Enables docker build ..
• Simplified caching in publish-keria.yaml

I have tested the workflow here:

• See runs: https://github.com/lenkan/keria/actions/workflows/publish-keria.yml
• See pushed images: https://hub.docker.com/repository/docker/lenkan/keria/general
• You can configure your fork with variables to publish to your own registry
  • DOCKER_REGISTRY
  • DOCKER_IMAGE_NAME
  • See working example: https://github.com/lenkan/keria/pkgs/container/keria

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.63%. Comparing base (1f22907) to head (b721a65).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #394      +/-   ##
==========================================
+ Coverage   86.60%   86.63%   +0.03%     
==========================================
  Files          25       25              
  Lines        5286     5298      +12     
==========================================
+ Hits         4578     4590      +12     
  Misses        708      708              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[m00sey]

    tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=ref,event=tag
            type=sha
            type=schedule,pattern={{date 'YYYYMMDD_HHMMSS'}}
            type=raw,value={{date 'YYYYMMDD_HHMMSS'}}

does this block create a tag for each of those types?
or only on that event?

[m00sey]

Which tags to use?

Historically we've just done the "releases" so 0.1.0 etc

However for integration testing with sig-ts I like the inclusion of pr/branch builds as well

Should we not just use ghcr as the main container registry? Seems simpler than managing releases on docker hub.

I don't see a reason right now to require docker hub - previous releases obviously went there but I don't think its a blocker that people update their deployments to point to a different registry...

Might be a question for a dev call.

[iFergal]

Which tags to use?

Generally as long as there's a githash one and tag/branch one LGTM. I probably wouldn't use the timestamp one personally.

Another one we use in Veridian is a combination of the githash and run ID of the github action, if that's possible. So that gha env var changes, or any non-determinism is captured - not a big deal though. (Though preferably it should be deterministic)

Should we not just use ghcr as the main container registry? Seems simpler than managing releases on docker hub.

According to devops lead on my team, Roberto, docker hub makes sense as it's the default for docker cli etc so makes discovery easier, and they are all free. We push to both for our forks.

[iFergal]

Changes LGTM - we can adjust if needed based on the discussion now or later imo.

[lenkan]

I am doing some tweaking. I think I can consolidate it since we already have the configuration for docker hub

[lenkan]

I have updated it now and consolidated into one workflow. I repurposed the publish-keria.yml workflow. It will not, in addition to workflow_dispatch, also publish to docker hub on push to main. It will only publish 'latest' tags on workflow_dispatch. See my updated description in PR. I have also included links to successful workflow runs on my fork.

[lenkan]

FYI, on our fork, where I also moved signify-ts into the repo. I ended up using tags like:

• x.y.z-dev.<commit_sha>

The tag is based of the version in pyproject.toml, and the pre-release suffix is appended on every push to main. This was needed because npm requires you to have a x.y.z style version number, and you cannot overwrite a previously published version.

So for example, if you have 0.3.0 specified in pyproject.toml:

• docker: weboftrust/keria:0.3.0-dev.abc123
• npm: signify-ts:0.3.0-dev.abc123

And for the "release":

• docker: weboftrust/keria:0.3.0
• npm: signify-ts:0.3.0

After the release, you would have to bump the version to 0.4.0.

[lenkan]

This would be superseded by #398