CI strategy for Gitlab
I have been working on the configuration of the staging gitlab instance recently. We managed to hook it up with both Circle CI and Appveyor, for the ghc/ghc (username/repo) project on our instance. It all works.
Things get tricky when it comes to running CI jobs for forks, though. Indeed, our Circle CI script relies on some CI env vars being defined in the CI settings of the project. Those are "secrets" (e.g circle ci API token) that we do not want to make public and encourage everyone to use, which means that CI simply won't work for forks, out of the box, with things as they stand. Ben and I have discussed this a bit and we see 3 different ways to go about this.
-
Forget about the fork-based workflow. We might consider having a reference repo where things get merged and a "sandbox" repo where people could push their branches and get some CI running. They could then create MRs against the "real" repo to get patches merged. This one way or another requires adding new contributors manually to the "sandbox repo". It is quite likely that they could also get "our secrets" by simply tweaking
.gitlab-ci.ymlto print the right env vars, in their branch. -
We go for a "full gitlab CI" solution, which might require less work than it initially seems as it could use the same docker images and run roughly the same commands as Circle CI. That requires computational resources though, and makes the transition less smooth. We can certainly consider doing some additional CI with this, if we make the move definitive and end up refining our CI needs, but we definitely don't want to get rid of Circle CI/Appveyor now anyway.
-
We implement a "mediator" service that would have all our secrets and would get hit by gitlab CI jobs to launch builds and report the results & artifacts. It could therefore behave the same regardless of the user/repo/branch that triggers it without exposing anything. This could be put together somewhat quickly but requires enough work that we may not be able to set that up in time for the initial move. It is however the best solution from the user experience (ghc contributor) point of view. People with developer access to the main repo could push there, or in their forks. Others would only push to their forks and create MRs. CI would work the same in all those cases.
In my opinion, going with 1) initially and then 3) as soon as possible is the best plan in the long term. It would make for a great contributor experience while requiring very little maintenance. This could also very easily live side by side with some "real" gitlab CI, that doesn't offload the work to an external service.
Trac metadata
| Trac field | Value |
|---|---|
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture |
Activity
added Ttask Trac import infrastructure labels
Thanks for the careful thought here.
If I push to a fork and want CI on my fork, I don't mind a few extra clicks, etc., to get CI working. (E.g., I might need to make an account somewhere and link it somehow.) Would requiring contributors to take a few steps like this unlock a better approach?
(Note: I really don't have any idea of what I'm talking about here, and it's not worth your time to offer a long explanation of why such a thing isn't possible. If this comment is not helpful, just say "no" and invest your time in building the solution you think is best.)
Hello Richard,
Yes, that could have been a possibility, to ask people to get a Circle CI account and get some token from there that they would put in some gitlab settings. But Ben and I decided to try 2) and 3). He's giving a shot at a minimal script that only uses gitlab's CI system, no external service, while I'm implementing 3). I'm confident that we can get at least one of these working sometimes next week
Edit: And with both implemented, we would (will, I think) have the ability to run more builds in parallel.
-
https://gitlab.staging.haskell.org/alp/ghc/-/jobs/578 shows that I managed to get a Circle CI job to run smoothly from my fork of the GHC repository on the gitlab instance. No project-specific settings, nothing. I deployed the necessary changes to the infrastructure.
All that is left to do is to push https://gitlab.staging.haskell.org/alp/ghc/commit/6f73d339d810604f053d49b1d040fe6aaa3a8b7f to master, AFAICT. I will make that happen and will then close this ticket once this lands on master and is confirmed to work properly for everyone.
added Pnormal label
