Add Makefile targets to create stable releases, add version.go and print version #35
Conversation
|
Note: version.go could print quite a few more information if we switched to go 1.18... |
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. Signed-off-by: Jakub Hrozek <[email protected]>
|
@JAORMX @bachradsusi could either of you take a look? They're just |
Makefile
Outdated
| commit-release-version: check-release-version | ||
| echo $(RELEASE_VERSION) > VERSION | ||
| git add VERSION | ||
| git commit -m "Release v$(RELEASE_VERSION)" |
There was a problem hiding this comment.
Given that git log contains commits with Signed-of-by, maybe git commit -s -m ... ?
Makefile
Outdated
|
|
||
| .PHONY: next-version | ||
| next-version: | ||
| # matches x.y.z where x,y,z are digits and then writes back x.y.99 |
There was a problem hiding this comment.
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.
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.
|
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. Signed-off-by: Jakub Hrozek <[email protected]>
|
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 log` contains commits with Signed-of-by, maybe `git 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?
|
|
CI keeps failing because of vagrant hub rate limit :-( |
Works for me. |
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. |
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:
1. (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.
2. (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. |
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.
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.:
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.