Show when the Dependency List was last updated
Problem to solve
In some cases the Dependency List of a project is not up-to-date: it doesn't reflect the HEAD of the default branch. Users should be warned that they're looking at the dependencies of an old, possibly outdated version of their project.
Intended users
- Delaney, Development Team Lead
- Sam, Security Analyst
Further details
The Dependency List API endpoint relies on a query that returns the latest build with Dependency List reports, so the dependencies returned to the client may come from an old pipeline that doesn't correspond to the HEAD of the default branch.
Proposal
additional notes:
- UI consistency with upcoming license list https://gitlab.com/gitlab-org/gitlab-ee/issues/13582 and familiar pattern (header w/
?
and clarifying subtext) on the dashboard https://gitlab.com/gitlab-org/gitlab-ee/issues/13298 - Proactively display the latest update, vs reactively displaying "warning" (that may not be valid)
- Better informs the user of what the data is and when it's updated
- Links to documentation - consider cases where the license list and dependency list support different languages (as first step surface documentation for better awareness)
- Showing a warning is a temporary solution (as discussed above). We currently have one job that runs the docker images one at a time. But, in the future, they may be running simultaneously; therefore, in this case, we will need to revisit this warning (https://gitlab.com/gitlab-org/gitlab-ee/issues/12487)
Previous UX ideation notes
When do we display messaging?
When the data has been collected from a commit, that is not the HEAD
of the branch.
Why would this be the case?
Depending on how the pipeline is configured, the latest commit to the branch may be processing and delay the most up to date data. This depends on the CI config and infrastructure bandwidth.
When is the warning updated?
As soon the latest dependency scanning job is complete and its data has been processed by the backend: we can show the list. It’s possible the dependency scanning jobs succeed, even if the pipeline fails. In this scenario will still show the data reported; hence removing the messaging.
Why is this temporary a temporary solution?
We currently have one job that runs the docker images one at a time. But, in the future, they may be running simultaneously; therefore, in this case, we will need to revisit this warning (https://gitlab.com/gitlab-org/gitlab-ee/issues/12487). In this scenario, we may have some data for the head of the branch but not all of it. It’s difficult to tell whether we have the data for the head of the branch in order to update the warning. This would result in uncertainty of when to show / not show the messaging. (cc @vzagorodny https://gitlab.com/gitlab-org/gitlab-ee/issues/10857)
What messaging do we report to the user?
The data comes from a commit that is not the HEAD of a branch anymore. Please check pipeline
to see when the updated list will be available.
Recommendation: add to our documentation specifies that: up to date information is provided when the data has been collected from a commit that is the HEAD
of the branch. The design would look like this:
- In the backend, change the Dependency List entity and make it return a distinct status when the build's pipeline was not triggered for the HEAD of the branch. https://gitlab.com/gitlab-org/gitlab-ee/issues/14705
- In the frontend, show a warning message when the backend sends this particular status.
- UX is as follows:
- Specifies why the data "may be out of date"
- Links to the pipeline (guides user to action to resolve)
- Links to documentation to understand how the list updates
Permissions and Security
Same as Dependency List.
Documentation
This UX improvement should be self-explanatory and there's probably no need to cover it in the Dependency Scanning documentation.
What does success look like, and how can we measure that?
- User is able to identify where the data is coming from
- User is able to identify when the data was last updated
- User is able to find where to learn more
?
(access to documentation) - if usage ping isn't blocked send ping when this is displayed to a user, otherwise strike this out
UX solution validation from: ux-research#360 (closed)
What is the type of buyer?
Compliance dept.
Implementation plan
- Return additional field in the response
report.generated_at