Migrate to a CI build with SLSA provenance #896
Conversation
This reverts commit 3a92ad9.
Signed-off-by: Pedro Kaj Kjellerup Nacht <pnacht@google.com>
|
@pnacht Thank you for the PR! I'll need to have another and hope to do that soon. One quick question: have I asked for CLA yet? If not, I'd need this: https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf before first merge (but only once, good for all future contributions, PRs etc). Looking forward to merging this! |
|
Ok, thank you again @pnacht. Aside from CLA (which I'll need) things make sense. There are 2 things, one smaller, one bigger that I am not sure about. Both are related to publishing of Release Candidates (current version numbering scheme being "2.15.0-rc1" etc -- apparently many Maven tools do not recognize So: I do need to publish these too, but would the idea be that I would just use the old method of using Maven release plugin outside of SLSA workflow? That'd be fine for me but not sure if that makes sense or not: maybe provenance aspects are important for (pre-) Release Candidates too, if we are to get users to test them? Aside from that I was wondering if tags to consider should be opt-in rather than opt-out? |
| on: | ||
| push: | ||
| tags: | ||
| - "*" |
There was a problem hiding this comment.
As per my note, should perhaps verify that the tag ends in something like "2.15.3"; although if Release Candidates were to use this workflow too (should they?) would need to accommodate those too.
|
Ah, I hadn't noticed that the RCs are actually published to Maven! I thought they were only used to test deployment to the Sonatype Nexus Staging area. As is, the workflow rejects RCs ( Provenance is as relevant for RCs as for regular releases, and as far as I'm aware, there's no reason not to add it to RCs once the infrastructure has been set up. As for the tag names, I can certainly make the filter more specific and validate it ( What do you think? Also, what should I do about the |
|
@pnacht Right, release candidates are indeed pushed to MC as that makes it easier for developers to test them. Having to use, say, SNAPSHOT builds means very few developers help with pre-release candidates (based on my experience). On |
|
Gotcha. One clarification for someone not fluent in Maven: will the parent pom (up to oss-parent) be fetched automatically? That is, can I simply set |
Sorry, missed this question. Yes, parent pom settings are inherited so you can just refer to that value. |
|
Sorry for the delay, but I've just made the requested changes. The workflow now uses |
cowtowncoder
added
the
cla-needed
|
Ok great @pnacht ! Just one question: looks like this runs for all tags, but validation step will fail for non-compliant tags: is this correct? Aside from that all I need is the CLA as per my earlier note, and then I can merge this PR. |
That's correct, the workflow only progresses past the first step if the tag name is compliant with the standard Release Plugin format. And if a compliant tag is pushed but lacks the For examples, see these workflow runs on my fork:
Slipped my mind! Just sent it over. |
cowtowncoder
removed
the
cla-needed
Closes #844.
CI build with SLSA provenance
As discussed in #847 (comment), this PR will allow jackson's maintainer to migrate from releasing on their local machine to a CI release, while keeping the
mvn release:prepareworkflow they're used to.This is done via the new
release.shscript, which:mvn release:clean release:prepare(without pushing to GitHub)When the new tag is pushed to GitHub, the new
release.ymlworkflow kicks in and performs the finalmvn release:performstep, as well as generating SLSA provenance.Work done by
release.shmvn release:prepareeffectively does three things:release.shhas to rewrite the commits created bymvn release:prepare.This is because
mvn release:performrequires arelease.propertiesfile that is created byrelease:prepare,* but that isn't actually committed. Sinceperformwill be run in the CI, we needrelease.propertiesto be committed as well.We must therefore rewrite the commits so that
release.propertiesis added to the first commit and then deleted in the second commit (so the final result is unchanged). In changing the commits, we also need to recreate the tag.Work done by
release.ymlThe workflow itself is straightforward: it checks out the code (on the commit tied to the pushed tag) and then runs
mvn release:perform.Once the release is complete, it calculates the jar's hash and uses it to create a SLSA provenance attestation file, which is added as a workflow artifact.
The workflow only runs on "pure" tags without metadata; tags ending with
-rc,.prorbare ignored (those were the variants I found in the project's list of tags, let me know if there are others you'd like to omit).Likely incorrect value
The workflow copied the
actions/setup-javaarguments frommain.yml, which likely isn't correct (especially theserver-id: sonatype-nexus-snapshots. Unfortunately, after checking out the pom.xml, I couldn't figure out what the correct ID would be.* Technically,
release:performaccepts command line arguments, but it doesn't work with GitHub URLs. And regardless, making the GitHub workflow rely onrelease.propertiesreduces the potential damage from accidentally pushing a random tag. In such a case, the workflow will simply fail.