Open emil-wire opened 3 hours ago
Thank you for taking your time to reach out. :heart:
@MediaMarktSaturn/software-supply-chain-security :eyes:
Thx for raising @emil-wire. There's a feature included, that writes the releases version to the dtrack project description for the given commit sha - but that doesn't work very reliable, haven't analyzed the reason yet.
But you're referring to a proper versioning in dtrack in general, don't you? so creating the project in the appropriate version in dtrack?
Would love this as well, but need to investigate how this would be possible. issue is, that every version of each project is analyzed in dtrack periodically, leading to many many permutations. An option could be to disable all previous projects versions but the current, but that's effectively the same like we have now with the default-branch as dtrack version.
Having separate version of a project also makes projects metrics per version, so that there's no single graph for the project, but one per version.
Haven't found a solution I'd be happy with, so looking forward to your input.
One (unrefined) idea: doing a full-analysis (sbom creation + dtrack project/version creation) for every github release as opt-in, so we would get the best of both worlds (single-project & per-version projects in dtrack). Dtrack will fail struggle with some thousand project/version permutations - but project Hyades will solve this.
Expected Behavior
whenever a tagged release is made in a given repo, that version number or tag should appear as version in dependency track. if no tag is available, a commit hash could/should be used (configurable?)
Actual Behavior
https://github.com/MediaMarktSaturn/technolinator/blob/e498723310e3b1f5c554877cb6ab56af243fa328/src/main/java/com/mediamarktsaturn/technolinator/git/RepositoryService.java#L116 -> this reports the branch only without any further information
Steps to Reproduce
No response
Additional Information
No response