stran merged https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/205

gitlab-ci: Remove security template

sbassett opened https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/208

Re-add OSV template and begin to debug security template behavior

Testing things out with MR208, I'm noticing some odd behaviors in Gitlab. Let me try to describe said behavior with some examples:

1. Looking at the pipeline history for MR208, I see pairs of pipeline runs for each commit I pushed to the MR, save the first commit I pushed which had a duplicate include key and therefore was bad yaml and just errored out immediately.
2. When I fixed the bad yaml issue, I got two pipeline runs for the new commit (36457, 36458), but only the last one, for osv_dependency_check, showed up within the MR's UI where it shows the latest pipeline status. But it appears all of the jobs ran successfully within 36457, even with osv_dependency_check failing, although technically it is allowed to fail via allow_failure: true.
3. I then experimented by also adding the commit-message-validator include file, which is a similar CI include file for Gitlab, but a separate project not maintained by the Security-Team. Again, two pipelines were created (36459, 36460), but the latter was the only one that showed up within the MR UI and then I noticed that the lint-code job (188262) started to randomly fail, even though the lint-merge-request job passed and the osv_dependency_check job status remained the same.
4. I then tried out the lint-merge-request job in isolation. Again, two separate pipelines were produced (36461, 36462). And again, the lint-code job seemed to randomly fail, blocking the run of the rest of the jobs, with the lint-merge-request job passing and the osv_dependency_check job completely removed.
5. Finally, I got rid of both the lint-merge-request and osv_dependency_check includes and everything ran fine within a single pipeline (36484).

I'd note that I've discussed (likely) related issues with the Release-Engineering-Team on Slack, but I don't think we fully understood what was happening. I feel like Gitlab's CI/CD might just be a bit buggy or introduce strange behaviors and unexpected results when various includes are used in different ways, which obviously isn't a great sign since a lot of our tools are designed to heavily leverage .gitlab-ci.yml includes.

We also have this problem in GitLab for AW team repos, e.g. on function-schemata!75's pipelines tab you can see two pipelines – one with OSV and the lint-merge-request, the other with OSV again and npm test. In practice, we manually check that 'both' pipelines pass, but GitLab lets you merge even if the pipelines don't pass…

Just looking around a bit online, it seems like this is actually "expected" behavior, and Gitlab is just creating separate pipelines for various events (a branch push, a merge request, etc.) After some more testing and having a look at the workflow described in https://stackoverflow.com/a/74574075, this appears to solve the "double pipeline" issue by "merging" all of the jobs into a single merge_request pipeline. The most recent pipeline run - 37269 - ran all of the jobs, including lint-merge-request and osv_dependency_check, and all jobs ended up passing, with osv_dependency_check throwing a non-blocking warning. And this was all done with a single pipeline run - see the pipeline history to confirm.

kharlan merged https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/208

Add OSV dependency check security template and new workflow