Closed netomi closed 10 months ago
Hi there, JReleaser author here. The tool does provide integration with SLSA
https://github.com/jreleaser/release-action/tree/java#slsa-builder
And an early example can be found at
ty for chiming in. I tested the slsa integration with jreleaser, but could not get it to work (the slsa generator stuff did not seem to work anymore in the latest releases in combination with the jreleaser slsa workflow). I will restart the effort, but wanted to have a workable solution quickly. The current workflow produces a slsa provenance as part of the release workflow. It still uses release-drafter which we also would like to abandon in favor of jreleaser.
Note that the java-builder requires a SLSA compatible manifest of all artifacts required for attestation. The SLSA cataloger https://jreleaser.org/guide/latest/reference/catalog/slsa.html takes care of that and will be automatically activated by the java-builder, which is why you may not see it explicitly configured in the demo.
Also, the demo still refers to the old location of the trw.yml
workflow. It's best to follow the instructions found in the readme of the java-builder. I'll update the demo shortly.
@aalmiray here is a link to the action using the slsa jreleaser builder: https://github.com/OtterdogTest/macos-notarization-service/actions/runs/6146753636/job/16677314601#step:5:65
it fails to checkout the tool repo which it somehow assumes from the builder repo which in your case is in a different org. I did not dig too deep into it, but as I said I will restart that soon.
JReleaser itself publishes SLSA provenance but does not use the java-builder. Rather it creates the attestation using the generic builder from SLSA -> https://github.com/OtterdogTest/macos-notarization-service/blob/6875c071d3d75cf9b01965e1ceebdeb3cb0a2725/.github/workflows/builder-jreleaser.yml#L84-L95
it did several experiments, referencing the trw.yml, copy it in my own repo, ... nothing worked completely, but its possible that I did something wrong or missed some setup.
Created https://github.com/eclipse-cbi/macos-notarization-service/issues/263 for tracing the switch to jreleaser.
Right now, after a release has been published by the existing workflow, the pom.xml has to be updated manually to the next development version. This should be fully automated like done here:
https://github.com/eclipse-xpanse/xpanse/blob/main/.github/workflows/release.yml
Ideally we should jreleaser, but it does not yet work in combination with slsa provenance generation.