Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency Graph weirdness for root component when using processing v2 #1026

Closed
2 tasks done
malice00 opened this issue Oct 3, 2024 · 8 comments · Fixed by #1048
Closed
2 tasks done

Dependency Graph weirdness for root component when using processing v2 #1026

malice00 opened this issue Oct 3, 2024 · 8 comments · Fixed by #1048
Assignees
Labels
defect Something isn't working p3 Nice-to-have features size/S Small effort
Milestone

Comments

@malice00
Copy link

malice00 commented Oct 3, 2024

Current Behavior

After activating v2 processing, the root component in a dependency graph is inconsistently rendered either as the name and version of the project (as it was in 4.11.x) or as a PURL. I'm not quite sure when/why it chooses to do one or the other, but I'd prefer it to use the previous way as to keep in line with all projects that were created before 4.12.

Steps to Reproduce

  1. Not sure, will do some more testing to try and figure out if this is random or reproducible

Expected Behavior

I expect the displayed name in the graph to be consistent between projects and prefer it to be the 'name version'-variant as it was before 4.12.

Dependency-Track Frontend Version

4.12.0

Browser

Mozilla Firefox

Browser Version

130.0.1

Operating System

macOS

Checklist

@malice00 malice00 added defect Something isn't working in triage labels Oct 3, 2024
@malice00
Copy link
Author

malice00 commented Oct 3, 2024

So, further testing seems to point at the fact that the projects that show 'name version' have sub-components defined in the SBOM (so metadata > component > components), whereas the projects that show the PURL have only a root component...

Maybe this is actually an issue for the DT repo? I started posting it here because I had this behavior in the UI, but now I'm not so sure if this is the right place...

@nscuro
Copy link
Member

nscuro commented Oct 3, 2024

Same cause as DependencyTrack/dependency-track#3978 (comment).

Processing V1 did not import metadata.component.purl into the project but V2 does. The code of the dependency graph prefers PURL over name+version:

createNodeLabel: function (identity) {
// could be a project or a component
if (identity.purlCoordinates) {
return identity.purlCoordinates;
} else if (identity.purl) {
return identity.purl;
} else {
let label = '';
if (identity.groupId) {
label += identity.groupId + ' ';
}
if (identity.name) {
label += identity.name;
}
if (identity.version) {
label += ' ' + identity.version;
}
return label;
}
},

Given that projects are otherwise referred to by name and version throughout the application, I do agree that the dependency graph should follow that, and consistently use name and version for the root node.

@nscuro nscuro added p3 Nice-to-have features good first issue Good for newcomers size/S Small effort hacktoberfest Issues eligible for Hacktoberfest contributions and removed in triage good first issue Good for newcomers hacktoberfest Issues eligible for Hacktoberfest contributions labels Oct 3, 2024
@nscuro nscuro self-assigned this Oct 9, 2024
@nscuro nscuro modified the milestones: 4.13, 4.12.1 Oct 9, 2024
nscuro added a commit to nscuro/dependency-track-frontend that referenced this issue Oct 9, 2024
nscuro added a commit to nscuro/dependency-track-frontend that referenced this issue Oct 9, 2024
@malice00
Copy link
Author

malice00 commented Oct 9, 2024

@nscuro I hate to say it, but this fix is not working for me...

@nscuro
Copy link
Member

nscuro commented Oct 9, 2024

How are you testing? Is it still showing the PURL for the project node?

It could be that the old version is still cached in your browser.

@malice00
Copy link
Author

malice00 commented Oct 9, 2024

You are right, resetting my cache fixed it! Should've thought of that myself...

@nscuro
Copy link
Member

nscuro commented Oct 9, 2024

You shouldn't have to do it. #1050 should void the need to clear caches manually.

@malice00
Copy link
Author

malice00 commented Oct 9, 2024

Great update, but that wasn't in the other branch I tested yet, so... 😉

@nscuro
Copy link
Member

nscuro commented Oct 9, 2024

Oh, yeah, I meant to say I took your experience as a reason to implement #1050. Since asking you to clear your cache made me realize how off that is. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect Something isn't working p3 Nice-to-have features size/S Small effort
Projects
None yet
2 participants