Design session notes: Committers workflow: move to Gitlab

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

Stefano: 2min summary: gitlab as CI infrastucture, not as code hosting, tickets etc;
  we have several improvements for gitlab CI, including tests on hw
  there are a bunch of build jobs, and also some run tests, most on qemu, but some on hw
  I'd like to give commiters and other notable community members a way to trigger a pipeline - it's as easy as git push to your repository
Julien: everyone can push, how it's prioritized?
Stefano: unfortunately we don't have prioritized, but increasing capacity is easy
  everyone can have a personal repo on gitlab
  but also: it would be nice to gate push to staging by gitlab pipeline
Marek: isn't the purpose of staging to be a pre-test master copy?
George: staging is fast-forward branch, cannot be rewind
Stefano: goal is to not allow bad commits even in staging
  committers would push to somewhere on gitlab and that only then it would go to staging on xenbits
  later: use merge request workflow:
  1. push to personal branch, open MR (git push -o ...)
  2. if pipeline passes, it can be merged to staging fast-forward
  3. 

Julien: maybe let osstest pull from gitlab?
Stefano: staging on xenbits is useful for legacy reasons
Marek: I have a script to push and pull stuff around in reaction to webhooks
Andrew: there is also stuff on github - FreeBSD testing, coverity testing, codeql code analyzer; generally github actions are nice
  it would be good to collect that state into common place (gitlab) too
Bertrand: can osstest be trigerred from gitlab?
George: the goal is to slowly move out of osstest into gitlab
Jan: I'm concerned about few things, for example conflicting merge requests
Bertrand: auto-rebase bot?
Julien: may introduce issues
Stefano: adding more capacity also reduces risk of such conflicts (smaller time window);
  two MR options:
  - merge commit
  - cherry-pick (rebase?)
Juline: when Jan is pushing, I'd like to know that when I'm pushing, to potentially adjust
George: maybe another bot that watches for MRs and see if they conflict to notify early (while pipeline is still running)?
Stefano: this can be another gitlab job
  and also, we can have a fast-fail job - if it fails, it stops the whole pipeline (earlier notifications, save resources)
Andrew: there are some non-deterministic errors, but also, there is a lot of noise (error messages that are harmless, basically bugs in the test)
Jan: to recap: first push to gitlab staging, then osstest, and only then to master; this increases delay
Andrew: security team must have a way to bypass public CI loop, but do testing in private first (private gitlab pipelines)
  but also, maintainers of runners implicitly will have access to that - this needs to be documented - like require them to be on pre-disclosure list
Jan: what about stable trees?
Stefano: most are okay with gitlab
Andrew: no, recent container change broke all stable trees :/
Stefano: we need George to cleanup permissions on gitlab - a lot of "Owner"s
Marek: what about removing osstests already covered by gitlab?
Andrew: that's stage 2


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]