Notice: PGP key changed / Release automation

[Cloudef]

The PGP key used now is 29317348D687B86B, I've signed this with the old key. The key can also be found from my website https://cloudef.pw/bemenu-pgp.txt

Also since the git archive doesn't seem to produce bit-by-bit compatible tarball to github generated one, the releases now include a tarball generated by the CI, thus if you want to verify the source tarball, do not download the github generated one. Instead get the bemenu-<version>.tar.gz and bemenu->version>.tar.gz.asc files.

[maximbaz]

This does produce a bit-by-bit compatible tarball for me, I'm using this command in many projects 😉

$ git archive -o "bemenu-0.6.0.tar.gz" --format tar.gz --prefix "bemenu-0.6.0/" "0.6.0"

You are free to create your own tarball, just sharing in case you are curious 🙂

[Cloudef]

https://github.com/Cloudef/bemenu/blob/master/GNUmakefile#L151
I guess the only difference here is that prefix should be bemenu-$(VERSION) I'll try that!

Tried it, sadly doesn't seem to work either

[maximbaz]

Tried it, sadly doesn't seem to work either

When I download these two files, they are identical for me, so I guess it did work? 🙂

[Earnestly]

Why have both GIT_TAG and VERSION in the sign target? Is there any chance for these two values to be different given the initial test condition?

[Cloudef]

@Earnestly it's to make sure the tag matches VERSION. I did mistake last time by not bumping VERSION file. Releases are automatically generated on tag pushes. #130

[Cloudef]

Tried it, sadly doesn't seem to work either

When I download these two files, they are identical for me, so I guess it did work? 🙂

Weird, it might be on my local machine it only differs but the github runner works 🤔

[Earnestly]

@Earnestly it's to make sure the tag matches VERSION.

This should be covered by the test condition; my point was more about the git archive command using a mixture of both VERSION and GIT_TAG instead of just using VERSION throughout. It shouldn't matter though as both would be the same value at this point, just odd. I thought it may be causing the issue seen here but it turns out to be harmless.

[Cloudef]

That's true. I guess my brain semantically mapped the GIT_TAG variable as a better candidate as a argument for git archive for a "git tag" :) Though it doesn't matter as both of them should be same the time the test passes.