ci: Build and publish docker image

[dark0dave]

Closes #303

[dark0dave]

@stepanstipl wdyt?

[dark0dave]

bump @stepanstipl

[stepanstipl]

Yep, so I was catching up on this. So let's first clean up the docker image, this was related to https://github.com/doitintl/kube-no-trouble/pull/302 and #304. I'm working on the the #304.

So I think the order of things is #304, resp. the PR for it -> Clean up docker image (scratch + some minor bits) -> this PR.

Otherwise first glance at the PR - I don't understand the .github/workflows/docker.yaml:

name: Publish Docker image
on:
  push:
    branches: ['release']
...

We don't have a branch release... what am I missing? I think docker image should get built as part of the normal main workflow, as it is in this PR, and published as part of the same workflow - perhaps part of release-artifacts or smth. like that, basically same as when we publish other artifacts.

[dark0dave]

@stepanstipl I updated the publish action

on:
  release:
    types: [published]

this should be what we are after.

The reason for separating these is to reduce the size and complexity of the main.yaml file, whilst keeping the docker image release separate to the binary release.

[stepanstipl]

Thanks, I think this is a bit better, but still couple of potential issues. A couple of Q:

• Will this work for nightly pre-releases? I think we want to publish Docker image for those as well.
• While I appreciate keeping the GH workflow files simple, I think a separate trigger and workflow adds more complexity than removes here. We add use of 2 different actions and introduce a new trigger.
• Related to the above - I would like to build docker images, and include links to the built images in the generated release notes, same as links to binary artifacts are added by GH (I'm not saying this should be implemented in this PR). How would it work in this workflow? (I understand the Docker builds would trigger only after the release).
• Related to that - what if Docker build/push fails, we have a release without Docker images?

And can you share an example of the full Docker image URL and what tags would be created? 🙏

[dark0dave]

• Yes it would work for nighties I can add for them too
• Well, the first trigger actually creates the release with the binaries in it, then the docker image gets published.
• We can pull them from the existing release.
• Shouldn't happen as the normal trigger for each release and main, has a docker build step in there (https://github.com/doitintl/kube-no-trouble/pull/312/files#diff-71cabc4177e41ea8f15a89eb65398fa8187739f68a2762706d84885cd8b2ddc3R67). If we break the docker build steps we can't make a release.

Sure, its should be doitintl/kube-no-trouble ( its just the name of the repo) full Docker image URL: ghcr.io/doitintl/kube-no-trouble:${commit hash}

[dark0dave]

@stepanstipl

• [x] Go back to scratch
• [x] full path to executable
• [x] add entry-point
• [x] Add to main workflow
• [x] Build before create release
• [x] Add to release notes
• [x] Use version and git hash for publishing and add latest (not for nighties)

[dark0dave]

@stepanstipl updated

[dark0dave]

I think all the changes are good. Almost there ;) pray Some minor bits noted in the comments. And apart from the circular dep. issue which I believe would cause the workflow to fail, only one point - are we adding the latest tag?

I am going to skip adding the latest tag for now. Lets get this landed.

[dark0dave]

I guess it's ok to leave the latest for later, we should create an issue in that case.

Latest has been added, I had to do some research