Now that core is focussing on GitLab CI, DrupalCI testing will start to rot. The security team needs a way to privately test fixes for security issues.
Initially, a private mirror on GitLab.com and using their runners was tried. Their runners have a hard limit of 3h. That is not enough time to complete jobs that take our overpowered CI runners less than 5m. A big part of that is we set up ramdisks at the runner level, so these are all likely using disks, whatever is cost-effective with Google’s Cloud for them. So GitLab.com is pretty much a non-starter for private security testing. Doing things the right way will be more straightforward than figuring out how to make a stopgap work.
Implementation
- Create a private group on git.drupalcode.org and sync security team membership to it
- Create a private fork of Drupal core within it and ensure testing arbitrary branches works
Future work
As #3265096: Move issues from www.drupal.org to git.drupalcode.org progresses, there will be the option to report confidential issues. These should be able to be triaged by the security team. That process is outside the scope of this issue.
Comments
Comment #3
drummThe basics of this are working now. The private fork of core is set up, security team members have access, and GitLab CI can start.