MediaMarktSaturn / technolinator

GitHub app for SBOM creation using cdxgen and upload to Dependency-Track
Apache License 2.0
14 stars 1 forks source link

[Bug]: technolinator not reporting correct version from git #566

Open emil-wire opened 3 hours ago

emil-wire commented 3 hours ago

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

github-actions[bot] commented 3 hours ago

Thank you for taking your time to reach out. :heart:

@MediaMarktSaturn/software-supply-chain-security :eyes:

heubeck commented 3 hours ago

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.