ci: fix issue SBOM not being triggered 🐛

[tungbq]

What?

Follow analysis provided in #3273

Putting the SBOM generation as part of the release process:

• Add Anchore SBOM Action as part of publish-github stage
• Remove .github/workflows/sbom-report.yml

Why?

Initially SOM was added in #3089 and tried to be fixed in #3254 - the sbom github action did not trigger for the v0.46.0 release.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make ci-like-lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

Closes: #3273

[CLAassistant]

All committers have signed the CLA.

[mstoykov]

I wonder if the asset detection wilkl "work" as such I do think it might be better if we actually output it to the dist directory and let teh create release below add it to the assets 🤔

Maybe also setting a bunch of the other options to false as action should not try to upload anything on it 's own now that we have it as part of the release

[tungbq]

Hi @mstoykov, I've just updated the Anchore SBOM Action to add the SBOM output to dist directory in my latest commit. It then be processed by the create release step to add to the release assets.

Also, the upload-artifact field should be true (the default value) in order to store the output file to the dist directory. I tested it on my repo by changing upload-artifact to false then we will not be able to retrieve the output file.
And the upload-release-assets can be false because we have our own release assets management process
Ref: https://github.com/anchore/sbom-action

[mstoykov]

Can we get the "continue-on-error:true" set.This seems way better for this step, it was added 2 releases ago and the only reason why we are actually fixing it is because we noticed. Nobody actually came to tell us it isn't working :)

[codecov-commenter]

Codecov Report

Merging #3279 (4501b4b) into master (cbd9e9a) will decrease coverage by 0.07%.
Report is 11 commits behind head on master.
The diff coverage is n/a.

❗ Current head 4501b4b differs from pull request most recent head e3fec1b. Consider uploading reports for the commit e3fec1b to get more accurate results

@@            Coverage Diff             @@
##           master    #3279      +/-   ##
==========================================
- Coverage   73.19%   73.13%   -0.07%     
==========================================
  Files         258      256       -2     
  Lines       19884    19879       -5     
==========================================
- Hits        14555    14538      -17     
- Misses       4405     4412       +7     
- Partials      924      929       +5     

Flag	Coverage Δ
ubuntu	73.13% <ø> (-0.02%)	⬇️
windows	?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 8 files with indirect coverage changes

[tungbq]

Can we get the "continue-on-error:true" set.This seems way better for this step, it was added 2 releases ago and the only reason why we are actually fixing it is because we noticed. Nobody actually came to tell us it isn't working :)

Sure! I added that flag on the latest commit. Please review again. Thanks!