Update legacy-release_sbom-generator.yaml

[rsh1k]

The workflow will generate the SBOM for each release in the release branch instead of core-test-results.

[dotcms-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[spbolton]

My only concern is that we are adding the commit After the commit we fix the release version and publish to github, therefore anyone actually looking at the files in the release commit will not see the sbom. Of course there is a chicken-egg problem here as the workflow is triggered off the release generation so the only way I see of fixing this would be to modify the main release workflow to add the steps before the release commit is created. It probably would be better to have the sbom combined with the single release commit, but a commit before would also be fine.
If
@bryanboza
is ok with this extra post release commit just to get the sbom in there in the short term, then I am ok with that. Otherwise to handle this before our release workflow refactor would be to modify the current release workflow to include the required steps rather than its own workflow as we currently have.

[sfreudenthaler]

@spbolton left a valid comment. I'm ok either way we go.

I do like that we're storing as a file in the root of the repo. Seems like a good pattern to have it by other repo metadata stuff like the readme. Appreciate that we're not creating the sbom file with the version in the filename and leveraging github versioning as well. It'll make future usage/programmatic consumption of the sbom much nicer to work with.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.