CI: Add automated SPDX SBOM generation workflow for releases#7505
CI: Add automated SPDX SBOM generation workflow for releases#7505ArthPatel1502 wants to merge 1 commit into
Conversation
|
Don't we already have some workflows used for releases? Could it be attached there? |
https://github.com/OSGeo/grass/blob/main/.github/workflows/create_release_draft.yml But more importantly, our code base is far from being adapted to SPDX, see #4190. |
|
The SBOM is not really related to the use of the license header. We don't really ship a with a lot of external dependencies bundled, as we have vendored and modified copies of some parts, otherwise the dependencies come from the package manager that packages grass. With the exception of docker images, which we could create these sboms (more regularly than only on releases). |
|
Thanks for linking the context from #4190, @nilason! I see the broader goal now. Luckily, as @echoix noted, our new release workflow scanner reads our top-level environment footprints rather than individual source headers, so this SBOM generation can safely land. Once this PR is in a good spot, I would love to look into helping with the automated script migration over on #4190! |
echoix
left a comment
echoix
left a comment
There was a problem hiding this comment.
It would also be nice to have a real example of you actually running that workflow in your fork, (probably in both triggers), to show that it works as intended, and I'm curious to see if there is really anything inside that sbom that syft can really find by only checking out the repo.
I don't think there would be anything; yet here's a PR adding support for it. I would have expected it to be looking at what we are actually releasing, and probably also our docker images; that's where we are distributing built software that isn't our own. But these images can also be updated when there aren't any releases made
| release: | ||
| types: [published] |
There was a problem hiding this comment.
How does this fit in the direction that GitHub has on making releases immutable ?
This is adding to the release once it is released (like, after the emails and notifications have been sent)
| - name: Checkout Repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Pin with trailing comment of the full semver version; renovate keeps both updated.
You most probably didn't look it up on how to assemble that workflow, as that action's major version is at least 6, not 4.
Read other workflows in the repo to get you started
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Generate SPDX SBOM | ||
| uses: anchore/sbom-action@v0 |
There was a problem hiding this comment.
v0? Doesn't seem right. Is it mature enough to be 0? Anchore makes syft, and it's really not that new.
| - name: Upload SBOM as Run Artifact | ||
| uses: actions/upload-artifact@v4 |
There was a problem hiding this comment.
As above, follow the same version as other workflows in the repo.
And v4 is really out of date. We're at least at 7. Have you looked on what each inputs do to be confident on what your proposing?
|
|
||
| - name: Attach SBOM to GitHub Release Assets | ||
| if: github.event_name == 'release' | ||
| uses: softprops/action-gh-release@v2 |
There was a problem hiding this comment.
Pin like others,it's also used in this repo. If my memory is right, a patch of 2.6.2 was released not too long ago, plus a v3 soon after.
| - name: Checkout Repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Probably would need to set one of the newer inputs that removes the git credentials after checking out since we don't need to push anything after that step; I'll let you read personnaly on what it is called, so you can learn more
| release: | ||
| types: [published] |
There was a problem hiding this comment.
Probably would need to double check who is the "actor" of the published event on releases. If the releases are triggered by CI with the GITHUB_TOKEN, then it won't be able to trigger another job automatically. (Because it is not a PAT, but that restriction is to prevent shooting ourselves in the foot).
| with: | ||
| name: grass-release-sbom | ||
| path: grass-sbom.spdx.json | ||
| retention-days: 90 |
There was a problem hiding this comment.
90 days would work only if the repo or org wide settings aren't limiting that below this nombre of days
|
Learn to read zizmor's output; there's some more improvements to your style that would be beneficial |
3 participants
Closes #7215
Proposed Changes
./workflows/sbom.ymlto handle software asset inventory.sbom-actionto systematically package dependencies into an industry-standard SPDX-JSON file format.grass-sbom.spdx.jsonartifact directly into the release distribution assets for seamless user download alongside binaries.workflow_dispatchaccess for dry-run validation profiles.Acceptance Criteria Addressed