Build and push official docker image following github tags

[Falx]

📁 Related issues

• Update CI pipeline to also build and push a docker image. #1111
• Public Docker image #1053
• Where to publish Docker container on Docker hub? #728

✍️ Description

This PR adds a docker job to the ci.yml workflow.

It should only trigger if the following jobs have been executed:

needs:
      # docs (edited: docs should not be here)
      - lint
      - test-unit
      - test-integration
      - validate-components

and if the ref_type is 'tag'.

For now, this should enable building and pushing of tagged versions following semver style.

Example:

Github tag: v1.2.3
Docker tags:

• 1
• 1.2
• 1.2.3
• latest (overwrites previous latest tag)

The necessary secrets should have been added by @RubenVerborgh.

✅ PR check list

Before this pull request can be merged, a core maintainer will check whether

• this PR is labeled with the correct semver label
  • semver.patch: Backwards compatible bug fixes.
  • semver.minor: Backwards compatible feature additions.
  • semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
• the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
• the RELEASE_NOTES.md document in case of relevant feature or config changes.

[RubenVerborgh]

      - docs

I don't see that one though; not a major issue in any case (and perhaps even better).

[RubenVerborgh]

Maybe temporarily remove the tag restriction to force a build?

[Falx]

I am all for building an image already, but the docker-metadata action uses the push tag event object to gather the version tag, so that would not work. We could add a commit that adds

tags: |
  type=raw,value=2.0.1
  type=raw,value=2.0
  type=raw,value=2
  type=raw,value=latest
  ...

And comment the if statement. Than after push, revert that commit?

[RubenVerborgh]

Or actually, just push a tag docker-test or so 😎

[Falx]

Or actually, just push a tag docker-test or so 😎

Same issue, semver type would not match and if statement would not allow (since no v prefix)

[Falx]

Let's try with my previous suggestion

[joachimvh]

I had a look at the docker meta action. Would it make sense to use type=edge for the versions/3.0.0 branch?

[joachimvh]

Let's try with my previous suggestion

I'm fine with this solution. But we could also manually create these versions and use automation for the future versions?

[Falx]

I had a look at the docker meta action. Would it make sense to use type=edge for the versions/3.0.0 branch?

Indeed, that was the idea. But I thought to first move on with the main build. Once that pipeline seems running and ok. I was going to add the other tags.

[Falx]

Let's try with my previous suggestion

I'm fine with this solution. But we could also manually create these versions and use automation for the future versions?

Agreed, that was a possibility. But using the CI pipeline gives us a chance to "validate" it before merging.

[Falx]

@joachimvh Do you have any idea why these variables are not being picked up? @RubenVerborgh Added them as repository secrets yesterday, and I should have write access. So normally my PR from my forked repo should be able to use these secrets in the triggered workflow/action.

[Falx]

So I found this https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/ (second section on public repos)

I think that if we change this line to pull_request_target:

That the proper write access is granted to PR pipeline runs (since the owner of the workflow will be the original repo and not the fork). This would however give everyone forking and PR-ing access to the secrets. I can't decide if that is ok..

Sidenote:
I am new to this repo, I thought common practice was fork and PR, but now that I was added to imec-staff: do I have access to create feat/ branches on this repo? Then I can just make a branch here and PR from that branch. That will probably solve all this secret nonsense..

[RubenVerborgh]

Indeed, just create a new PR with a branch from this repo.

[Falx]

Ok, I will close this PR and do a new one from a branch on this repo. That should work.