containers
Add Makefile targets to create stable releases, add version.go and print version
- Print deamon info on startup
Adds a VERSION file with the current daemon version, sets the NVR from that file as a string during build and prints that version along with other information during the daemon and oneshot commands so that operator using selinuxd as an operand can know what exact selinuxd version was being used.
- Add release Makefile targets
Adds several Makefile targets to help create stable releases. The top-level one is "make releas" which should be called with a RELEASE_VERSION variable, e.g.:
make release RELEASE_VERSION=0.3.0
Doing that changes the VERSION file, commits and tags that commit with the release version. Then, images using both Fedora and CentOS are built using that version as the tag instead of latest and pushed, finally the same images are built and pushed also using :latest.
Note: version.go could print quite a few more information if we switched to go 1.18...
@JAORMX @bachradsusi could either of you take a look? They're just make targets for the most part, so we can iterate on them later, but I'd like to start using some sort of versioned releases and not just use a snapshot of master downstream.
Note: version.go could print quite a few more information if we switched to go 1.18...
why don't we?
@jhrozek what about instead changing to a purely GH-action based release model? I've been experimenting with this a bit and it's quite clean and simple https://github.com/metal-toolbox/auditevent/blob/main/.github/workflows/release.yml
all you need to do is push a tag and things happen magically 😄 ... if you want extra magic, we could use https://goreleaser.com/ which also automates changelog settings and multi-arch support.
On Thu, Apr 21, 2022 at 10:36:16AM -0700, Juan Osorio Robles wrote:
Note: version.go could print quite a few more information if we switched to go 1.18...
why don't we?
We can :-P since SPO switched as well. I didn't want to mix two changes in one PR is all.
On Thu, Apr 21, 2022 at 07:38:54AM -0700, Petr Lautrbach wrote:
@bachradsusi commented on this pull request.
@@ -126,3 +151,31 @@ vagrant-up: image.tar ## Boot the vagrant based test VM
Retry in case provisioning failed because of some temporarily unavailable
remote resource (like the VM image)
vagrant up || vagrant up || vagrant up + +.PHONY: check-release-version +check-release-version: +ifndef RELEASE_VERSION
- $(error RELEASE_VERSION must be defined) +endif
+.PHONY: commit-release-version +commit-release-version: check-release-version
- echo $(RELEASE_VERSION) > VERSION
- git add VERSION
- git commit -m "Release v$(RELEASE_VERSION)"
Given that
git logcontains commits with Signed-of-by, maybegit commit -s -m ...?
Sure, done.
On Thu, Apr 21, 2022 at 07:52:57AM -0700, Petr Lautrbach wrote:
@bachradsusi commented on this pull request.
+.PHONY: check-release-version +check-release-version: +ifndef RELEASE_VERSION
- $(error RELEASE_VERSION must be defined) +endif
+.PHONY: commit-release-version +commit-release-version: check-release-version
- echo $(RELEASE_VERSION) > VERSION
- git add VERSION
- git commit -m "Release v$(RELEASE_VERSION)"
- $(eval VERSION = $(RELEASE_VERSION))
+.PHONY: next-version +next-version:
matches x.y.z where x,y,z are digits and then writes back x.y.99
This somehow blocks the possibility to make a minor release like 0.3.1 as the version would be 0.3.99 right after 0.3.0 is released.
Hmm, fair point, I changed the sed to do a x.y.z.99. That's also not ideal (I guess someone, somewhere expects only x.y.z) but the version is not really used much in between releases except printing the string in the deamon and at least it's all just numbers (as opposed to x.y.(z+1)-dev that SPO uses)
What do you think? Do you have any other proposal?
Hmm, fair point, I changed the sed to do a x.y.z.99. That's also not ideal (I guess someone, somewhere expects only x.y.z) but the version is not really used much in between releases except printing the string in the deamon and at least it's all just numbers (as opposed to x.y.(z+1)-dev that SPO uses) What do you think? Do you have any other proposal?
Works for me.
@jhrozek what about instead changing to a purely GH-action based release model? I've been experimenting with this a bit and it's quite clean and simple https://github.com/metal-toolbox/auditevent/blob/main/.github/workflows/release.yml
all you need to do is push a tag and things happen magically smile ... if you want extra magic, we could use https://goreleaser.com/ which also automates changelog settings and multi-arch support.
Sorry, for some reason, I didn't reply to this (I thought I did).
The main reason was that I would have to give some kind of an API key to the GH action and I was uneasy about this because we have a shared repo with SPO. I don't know enough about quay accounts, maybe we could create some account that could only push to the selinuxd repo and not the others in the quay SPO org.
Your action uses the GH's ghcr.io registry, did you not have to give the keys to the action? Maybe the GH's registry is better integrated with GH actions?
But, I really like that the containers are signed with cosign in that action and I see in the docs that they support also quay repos. That tempts me.
Your action uses the GH's ghcr.io registry, did you not have to give the keys to the action? Maybe the GH's registry is better integrated with GH actions?
GitHub's container registry can be natively used by GitHub actions, actions already have tokens that the registry accept, so you just need to use the env variables.
OK, while we debate how to release the tagged images upstream, I've opened #37 that just uses tag (if exist) to print the into on startup. Having the tag in the repo would unblock my downstream builds.
On Thu, Apr 21, 2022 at 10:38:22AM -0700, Juan Osorio Robles wrote:
@jhrozek what about instead changing to a purely GH-action based release model? I've been experimenting with this a bit and it's quite clean and simple https://github.com/metal-toolbox/auditevent/blob/main/.github/workflows/release.yml
all you need to do is push a tag and things happen magically 😄 ... if you want extra magic, we could use https://goreleaser.com/ which also automates changelog settings and multi-arch support.
As much as I like the automation aspect, there's two things I don't like. But maybe I'm missing something, because I'm not super versed with GH actions:
-
(minor) I would like to have a way to release w/o github as well. Because these makefile targets took me about 2 hours to write, (well, write.."borrow" from other projects is more like it..) it's not really a deal breaker for me.
-
(major) Would this work without giving the release action some kind of API key to the spo org at quay.io? The script you linked pushes to ghcr.io which is their container registry, but our images are hosted at the SPO quay org.
I like the cosign support in the actions though and it looks like they support quay as well..
@jhrozek supporting quay wouldn't be too problematic, all we need is a token and admin access to this repo. With admin access we're able to store the token in GitHub's secret registry and make it accessible to actions.
point 1. is possible, but I actually would rather not give developers support for releasing 😄 ... but that's just me.