Configure SAST analyzers CI to trigger blocking bridge non-DinD jobs for test projects
Background
In order to properly test and QA our analyzers and their wrapper Secure projects we should setup multi-project pipelines to trigger downstream executions of our test projects from analyzer projects. We currently rely on either manual testing or analyzers' included test/fixtures
to ensure there are no regressions. This is time consuming and not very efficient.
We recently introduced new jobs to CI templates in order to trigger test project's pipelines. We done configuring those for in Dependency Scanning analyzers. We should do the same for SAST analysers. You can see how it is done in Dependency Scanning here or you can simply check gemnasium-python
Tasks
- For each of the analyzers below with existing test projects, add CI job for master/tags to trigger downstream QA projects. Please keep current integration tests in place as that will give us test coverage on MR branches.
- Update release process docs to explicitly state that master must be passing before creating a tag to release a new version.
Current State
As of May 22, 2020, the MRs that have been created add downstream pipelines that use DinD (via the SAST orchestrator). But, the intent of this issue is to use non-DinD and avoid the SAST orchestrator.
While the downstream DinD pipelines add coverage, this issue should not be considered closed until we have non-DinD coverage given that non-Dind is now the default.
No DinD implementation plan
- Engineers add their name in the column(s) for projects in which they want to call dibs.
- If a
no_dind-FREEZE
does not exist, create it via MR. - Create an MR against the test project's
no_dind-FREEZE
branch to add SAST to the CI, configured without DinD. - Add MR establishing a no-DinD configuration to the matrix.