We've already deprecated the DinD mode and switched to non-DinD by default. We now need to officially drop support for this mode. Also, we should stop testing the DinD mode to simply QA for SAST and Dependency Scanning.
DinD for SAST and Dependency Scanning are no longer tested. The test projects are used to test the no-DinD setup where each analyzer runs in its own CI job. In particular, the master branch of all test projects is used to check the default no-DinD setup.
What does success look like, and how can we measure that?
SAST and Dependency Scanning no longer support DinD mode.
@NicoleSchwartz@tmccaslin I've set this to %Next 1-3 releases for now, please prioritize as needed. I'd suggest %13.4 to be a good candidate so that we have enough maturity on non-DinD mode to confidently remove support for DinD.
Thanks @tmccaslin. I'm setting this to %13.4 then with a due date to make it clear it's a deadline. Though, we may want to start looking at this earlier
depending on refinement output, to make sure we're ready to ship in %13.4
merge the no_dind-FREEZE branches into master, in all test projects
rebase some *-FREEZE branches, so that they don't use the DinD mode
possibly rename some no_dind-* branch, and change their target branch
So there's quite a lot of cleanup involved in removing DinD, in the test projects. Hopefully we'll benefit from this cleanup when maintaining these test projects!
although this might be covered well enough with #33724 (closed)
Merging no_dind-FREEZE into master is not covered by the issue. Also, the issue is specific to SAST.
@gonzoyumo At this point (based on the current implementation plan), I believe it would take me about a week to do all this, so the weight would be 5. That said, the review is likely to spread over a couple of weeks, because of the many MRs involved in resolving this issue. In any case, I'd say it's no more than 8. Actually, someone not totally familiar with the DinD mode and the QA is likely to spend a couple of weeks on this.
À weight of 8 is a bit high, we should look for a way to break this down further. @caneldem could you please make a proposal to extract some pieces that won't be mandatory to have in this release? (in case it's slipping, it should not impact customers or our development workflow)
Nicole Schwartzchanged title from Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning to Plan and refine: Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning
changed title from Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning to Plan and refine: Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning
Olivier Gonzalezchanged title from Plan and refine: Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning to Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning
changed title from Plan and refine: Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning to Drop support of Docker in Docker (DinD) mode for SAST and Dependency Scanning
@fcatteau, @gonzoyumo - FYI that I added one item to the implementation plan to remove SAST_DISABLE_DIND from analyzer.yml. Please let me know if you'd like me to execute that addition as I am happy to pick up that extra bit of scope.
@gonzoyumo A little update on this issue. It's more complicated than I initially thought because the SAST configuration parser relies on the sast job; this job is used by the DinD configuration, and to me it should be removed. See !40989 (comment 405783292). I'm exploring options. cc @twoodham
To repeat what I said in the MR, I eventually decided to keep the sast job, and I've also kept dependency_scanning to keep both CI templates consistent. Issue is now on track.
The update of the test projects conflicts with #225240 (closed), so I'll handle this when @adamcohen is done pinning the version of gemnasium-db in test projects supported by Gemnasium. cc @gonzoyumo
@adamcohen I still have to update all these test projects and I'd like to try something else this time around. Since approval isn't required in test projects, and since the MRs I'm about to create are fixing the QA, what about having me merging my own MRs, and you reviewing them after the fact?
To my experience the review we did for #217790 (closed) was not really practical. WDYT?
I still have to update quite all these test projects and I'd to try something else this time around. Since approval isn't required in test projects, and since the MRs I'm about to create are fixing the QA, what about having me merging my own MRs, and you reviewing them after the fact?
@fcatteau I understand the pain about updating all the test projects, I'm fine with reviewing them afterwards.
@gonzoyumo Based on the discussion we had yesterday, should I create a follow-up issue for the update of the test projects, put that in %13.5, and close this one? cc @NicoleSchwartz