Migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS
Problem to solve
Right now, if you want to avoid running one particular DS analyzer, you need to remove it from the long string of analyzers and use that to set the DS_DEFAULT_ANALYZERS somewhere in your project's CI template. And, if you do this, it excludes you from future new analyzers. This gotcha is not obvious.
User experience goal
It should be easier for a user to avoid running a particular analyzer without the risk of losing out on getting to use newly added analyzers.
Proposal
We could add a DS_EXCLUDED_ANALYZERS variable which would define the analyzers that the user wants to avoid running.
Proposed Removal in %14.0
Implementation plan
Step 1: add DS_EXCLUDED_ANALYZERS variable
-
update Dependency Scanning template to add
DS_EXCLUDED_ANALYZERS: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml 1 -
update documentation of
DS_EXCLUDED_ANALYZERSvariable, indicateDS_DEFAULT_ANALYZERSis deprecated: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-variables
Step 2: to be done after official deprecation (not in this issue):
- update development templates to use
DS_EXCLUDED_ANALYZERS: #333582 (closed) - Remove
DS_DEFAULT_ANALYZERS: See #333299
Notes:
- This must be added alongside
DS_DEFAULT_ANALYZERS(i.e. not replacing the old variable) so as to not break existing user configurations.
Further details
Only the DS analyzers that are relevant for a project are ran, so this variable can be left blank and only the appropriate analyzers will run.
Limitations
The current proposal would only work with Docker in Docker disabled, which is currently the default and will be the only way to run DS in the near future.
Docker in Docker is no longer supported, so the above is no longer a problem.
Risks
Removing/renaming DS_DEFAULT_ANALYZERS could have unintended consequences. Removing it would break QA is it works right now.
Documentation
Timing
The work should occur in 13.10 but not be default until as close to 14.0 as possible - if these both can coexist at the same time, great!
We'll also probably want to make a backlog item specific to 15.0 for full removal
Release Post
this MUST be announced in 13.9-14.0 per policy
Changelog
- This MUST be announced in 14.0 changelog
Blog post
Testing
SET could add an end to end test such that the pipeline is checked before and after setting this in CI.
expect(pipeline).to have_job('dependency_scanning')
# Set EXCLUDED
expect(pipeline).not_to have_job('dependency_scanning')