dependency_scanning: shouldn't set `dependencies: []`
Ask
Please update documentation so that users understand what we are doing (for speed and efficiency), there is a separate backlog item to change the behaviour.
Don't let a local optimization (template hardcoded dependencies: []
) prevent a more global one provided by GitLab's Directed Acyclic Graphs.
Summary
Contrarily to sast
for instance, dependency_scanning
sets dependencies
to an empty array.
This is annoying when favoring Directed Acyclic Graphs because one can't use needs
to define upstream job(s) artifacts and has therefore to resort to override dependencies
.
Steps to reproduce
- In a first
stage
, have an upstream job archiving some artifacts - In a second
stage
, add any of thedependency_scanning
jobs (s.a.gemnasium-maven-dependency_scanning
) to the pipeline definition - With
needs: [<upstream job>]
:- Override (or extend) the above job so that it
needs: [<upstream job>]
artifacts - Run the pipeline
- When run, the
dependency_scanning
job does not retrieve artifacts from upstream job
- Override (or extend) the above job so that it
- With
dependencies: [<upstream job>]
:- Now, change the above job by replacing
needs:
withdependencies:
- Run the pipeline
- When run, the
dependency_scanning
job now retrieves artifacts from upstream job
- Now, change the above job by replacing
What is the current bug behavior?
needs
doesn't work for dependency_scanning
jobs.
What is the expected correct behavior?
needs
should work for dependency_scanning
jobs.
Possible fixes
Remove dependencies
from dependency_scanning
.
Implementation plan
Note: see comment #249569 (comment 436961514) We can't quickly address this issue so the first step is to add a note to documentation:
- Add note to https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#limitations that
dependency_scanning
doesn't work with DAG right now. - Add a link to #257949 to show when I will be fixed.