| 1 |
On Tue, 26 May 2020 20:24:56 -0700 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> The TL;DR is that a crack team of infra-folks[0] have been putting |
| 5 |
> together demos of CI services and things like gitlab / gitea / gerrit |
| 6 |
> and so on. |
| 7 |
> |
| 8 |
> Some of these come in combined (e.g. gitlab offers repo hosting, code |
| 9 |
> review / pull reqs, CI services, and deploy services.) Some of these |
| 10 |
> are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea |
| 11 |
> offers repo-hosting but CI is separate (e.g. drone.) |
| 12 |
> |
| 13 |
> On the infra-side, I think we are pretty happy with repo-hosting |
| 14 |
> (gitolite) and repo-serving (gitweb). We are missing a CI piece and a |
| 15 |
> pull-request piece. Most of the users using PRs use either a gitlab |
| 16 |
> or github mirror. |
| 17 |
> |
| 18 |
> I think the value of CI is pretty obvious to me (and I see tons of use |
| 19 |
> cases in Infra.) We could easily build CI into our current repository |
| 20 |
> solution (e.g. gitolite.) However gitolite doesn't really support PRs |
| 21 |
> in a uniform way and so CI is mostly for submitted code; similar to |
| 22 |
> the existing ::gentoo repo CI offered by mgorny. |
| 23 |
> |
| 24 |
> If we build a code review solution (like gitea / gerrit) would people |
| 25 |
> use it? Would you use it if you couldn't merge (because the code |
| 26 |
> review solution can't gpg sign your commits or merges) so a tool like |
| 27 |
> the existing pram tool would be needed to merge? |
| 28 |
> |
| 29 |
> -A |
| 30 |
> |
| 31 |
> [0] Mostly arzano, if I'm honest. I am just the point-y haired |
| 32 |
> manager in this effort. |
| 33 |
|
| 34 |
There are several CI systems that could be used. As for CI, my |
| 35 |
experience has been with buildbot. It would be fairly straightforward |
| 36 |
to integrate with the current gitolite/gitweb hosting. |
| 37 |
It is also extremely flexible in its capabilities, although can be |
| 38 |
difficult to master. It has a good web interface, but it can even be |
| 39 |
run via it's API's using curses, python, bash,.... There is a |
| 40 |
buildbot-travis plugin which is capable of running existing .travis file |
| 41 |
configurations. It also extends its capabilities to include custom |
| 42 |
buildbot step definitions. I have not packaged it yet for gentoo, but |
| 43 |
it is on my todo list. One of buildbot's capabilities is the ability to |
| 44 |
run tests/builds on multiple workers (different arches or whatever) |
| 45 |
both in parallel or series. It could be made to integrate with our |
| 46 |
bugzilla using the python client (pybugs was it?). |
| 47 |
|
| 48 |
But that still leaves a PR/code review option. |
Archives