Add GH Actions workflow for rebuilding the Docker image

[juhoinkinen]

This is a simplified version of PR #713: instead of doing rebuilds automatically with a schedule, this just intends to use the "workflow dispatch" trigger to manually start the build.

The Docker images of "maintained" releases should be rebuild regularly for system package updates, but this can be done manually (and for Annif deployments it is probably a good idea to have manual control on when updates happen).

For now is probably enough to consider only the most recent release to be "maintained" in this sense, but any tag (since merging this PR) can selected for rebuild.

This PR adds a GH Actions workflow, which

1. checkouts the git tag of the selected release
2. builds the image and tests it with pytest
3. pushes the image to quay.io with these tags of the release:
   • <major>.<minor>
   • <major>.<minor>.<patch>
   • <major>.<minor>.<patch>-<YYYYMMDD> (date of build)

The date suffix allows pinning to a particular build of Annif's Docker image (assuming only one build per day), which is necessary also to retain a tag on an image, which would otherwise be purged from the quay.io repository, making pinning with manifest digests impossible.

The date suffix is also added to the image tags when doing the (initial) image builds for Annif releases.

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (51db308) 99.67% compared to head (6dbebbb) 99.67%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #715   +/-   ##
=======================================
  Coverage   99.67%   99.67%           
=======================================
  Files          89       89           
  Lines        6380     6380           
=======================================
  Hits         6359     6359           
  Misses         21       21           

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[osma]

LGTM. I suppose you intend to close #713 in favour of this PR.

A couple of questions in the comments.

[osma]

Are we sure this always corresponds to the most recent release? I suppose this will always be triggered from the main branch, so it should give the last tag on the main branch. But there could be more recent tags on other branches, for example patch releases like v0.61.1.

At some point we had tags like v0.55-dev but those are no longer used AFAICT.

[juhoinkinen]

Only now I noticed that it is possible to select the tag to be used as an input to the workflow_dispatch:

I'll check how that could be used for the build step, so this a flaky way to select the tag for latest release can be removed, and the Annif version for which Docker image to be rebuilt could be freely selected.

Unfortunately the workflow_dispatch trigger can be used only when the workflow in question is already in the default branch, so testing this while in PR is not possible.

[juhoinkinen]

As noted in #715 (comment), it is now made possible to select the wanted git tag when triggering the workflow_dispatch (I tested this with my own fork).

However this is possible only for the tags from the point since the rebuild workflow is added to the main branch, i.e. for the next release on. Luckily the Docker image for Annif v0.61 got rebuild when working on this PR.

EDIT: but again the current development version of Annif ends up in the image. No good to merge.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[juhoinkinen]

EDIT: but again the current development version of Annif ends up in the image. No good to merge.

So stupid: ofc the current development version ends up in the image, because the tags which I created for testing this workflow were pointing to the current development version (1.0.0-dev).