Closed aethernet closed 3 months ago
The structure looks good to me in general. What made you decide to go with separate jobs for the sbom generation?
In some cases it makes sense to keep the steps separate, but in this case their seems to be enough duplication between the test jobs and the sbom jobs that we could simply add them as conditional steps at the end of the test job?
It would be faster if they just tacked on to the end of test jobs, and reduce the glut of jobs in the list, but if there are good reasons for keeping them as separate jobs that's fine too.
What made you decide to go with separate jobs for the sbom generation?
Mainly because the test job uses a matrix and there's no need to generate a bom for each version of node or python, etc. Maybe there will be cases where it makes sense, but for now I think we're good with one per project.
I started with a single sbom generator using if:
to choose the correct language, but it felt cleaner this way.
I think this version is ready (unless you'd prefer for me to add variables to opt-in/out). Setting up a d-track server and configuring it is not required to start producing these assets.
This should automatically generate an sbom for nodejs projects using cyclonedx and add upload it to the assets. Once this works, the next step will be to publish it to a central dependency-track server.