Update legacy-release_sbom-generator.yaml

[rashik1144]

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

[dotcms-sonarqube[bot]]

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.

[github-actions[bot]]

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.

[github-actions[bot]]

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.

[github-actions[bot]]

This PR was closed because it has been stalled with no activity.