avoid conflict with existing sbom and sources assets

[deitch]

We were generating the sbom and sources with each arch in the Actions matrix, but then uploading with a unified filename. This causes a conflict with the existing file, showing errors like this

This changes it to include the architecture in the asset name, so it will not conflict.

[eriknordmark]

LGTM

[deitch]

This begs the question whether we should have the sbom and sources for each architecture on the assets page.

On the one hand, they can differ slightly (should be minimal, but it is possible to be non-zero). On the other hand, especially with the sources, that can be pretty big.

This PR generates it for each arch. Alternative options:

• generate sbom and sources for each arch (this PR currently)
• generate sbom (small) for each arch and sources just once (a bit off)
• generate sbom and sources just once (might be slightly off, but still pretty good)

[eriknordmark]

This begs the question whether we should have the sbom and sources for each architecture on the assets page.

I wouldn't be surprised if we end up with more differences for the kernel for ARM builds; today we include all source even if it is specific to one arch but not clear it will stay that way as we learn more about ARM boards and required variants. So having unique names is a good idea.
Question is whether we need to build and publish anything but AMD64 for now; can we easily do that?

[deitch]

Question is whether we need to build and publish anything but AMD64 for now; can we easily do that?

We can. We either can put conditionals on the source and sbom generation and asset uploads; or we can pull them out of the matrix and give them their own step.

Based on your comment, though, about them diverging, I am not sure we should. If we are going to need them all soon anyways, why not just leave them there?

[eriknordmark]

Based on your comment, though, about them diverging, I am not sure we should. If we are going to need them all soon anyways, why not just leave them there?

As long as the built time impact isn't too bad that's fine.

[deitch]

Fair enough. If it gets bad, we can update it.