Design session notes: Committers workflow: move to Gitlab

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

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: signature.asc
Description: PGP signature