From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 323C41382C5 for ; Wed, 27 May 2020 08:28:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CECC2E0998; Wed, 27 May 2020 08:28:15 +0000 (UTC) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9EC3BE0986 for ; Wed, 27 May 2020 08:28:15 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id nr22so10632313ejb.6 for ; Wed, 27 May 2020 01:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HtRs+1MIrYM+iXhBhsWU++dTG4Xs5FxuLaRzsjgyJ3g=; b=qt/QDRz4cZ7OBiPgwZ5MWt65ScUgzv5j1g8xSDlyGsqa+mTo3LoRAWzNppaqnqnA5n C8ZIBpojyCQV16ZUdPfZ73dPyfUChFHtGOBQGQidKyAlbruN8rR/Y4ie4IHYVpQYblIN h/fo9uYr1783honT7HnaXGWXb/HJYzn/XfCk/9j+vXACaB1aFsGTAXRNJ9xLrxD8aeb6 N3CGWRuRLQa4sQEBHUtLMHOlDLqg9bmxNerhPnvc+vqb/Bo/BZ4bGK15uHwnpBJVF4aF 3JdmXyhZDgW0b7rNfpDxcgpW2xQSbl1oIj/kgTL199hRrtrOeJF78HTr9SbiaN1FCc7d mFCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HtRs+1MIrYM+iXhBhsWU++dTG4Xs5FxuLaRzsjgyJ3g=; b=JaHiGaW/35YHuHlV6ni+mVQaIcZzWillnsj8+TfaOQ1bkNW6abYnIUh/fYXAaVmynl 6LQWvrzLCjtUt0P5TB5vjrmx5QHqVhvl4S3rNOQvouSbOad54+kE3T6RATy3+q06Q2Bt c/t3SSys1oNRVoeAPb+p8j+Ad2NVujKHajMJdsqj9G3KRLquF+hQMbgo868upce6nQQM 0YUDONNkClJ5jx3HZN6OMttJRcUD63ICu4DGs5WX1ytdbv8n2CGZIHst/BBqrntkrTws b+Cwvt3raq7uQjHWQn4pu9Qz3sTh0LYKHkvAV1RbO+3zVLCsvBcZQWlvl/sj+/yKRX9U YJ3A== X-Gm-Message-State: AOAM5332udUCvYYKRnYgqfRSU/RqaKF8xVs4Q/6ikTAaBHpL6plPY7cF g7B/PzYB71FfW+wT+7uxef9NWIa4uDxymuZKl29kcSfo3wo= X-Google-Smtp-Source: ABdhPJzoLb4Uu+9N1Nj6tob+pMeL1xSP/1oANrjhP1gU9ZP2A1xzdEwwFXUa0ABI93Iju2fQ6M8nqzFRk1b7QIPIdeY= X-Received: by 2002:a17:906:57c5:: with SMTP id u5mr4710939ejr.419.1590568093768; Wed, 27 May 2020 01:28:13 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20200527010907.4ebd5160@storm> In-Reply-To: <20200527010907.4ebd5160@storm> From: Alec Warner Date: Wed, 27 May 2020 01:28:02 -0700 Message-ID: Subject: Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000387a6105a69cfe42" X-Archives-Salt: 3ae437c5-3fd1-4582-9e21-67721017c20e X-Archives-Hash: 510a8e8796b6bd3e0f1c2c1a9c4f0680 --000000000000387a6105a69cfe42 Content-Type: text/plain; charset="UTF-8" On Wed, May 27, 2020 at 1:09 AM Brian Dolbec wrote: > On Tue, 26 May 2020 20:24:56 -0700 > Alec Warner wrote: > > > The TL;DR is that a crack team of infra-folks[0] have been putting > > together demos of CI services and things like gitlab / gitea / gerrit > > and so on. > > > > Some of these come in combined (e.g. gitlab offers repo hosting, code > > review / pull reqs, CI services, and deploy services.) Some of these > > are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea > > offers repo-hosting but CI is separate (e.g. drone.) > > > > On the infra-side, I think we are pretty happy with repo-hosting > > (gitolite) and repo-serving (gitweb). We are missing a CI piece and a > > pull-request piece. Most of the users using PRs use either a gitlab > > or github mirror. > > > > I think the value of CI is pretty obvious to me (and I see tons of use > > cases in Infra.) We could easily build CI into our current repository > > solution (e.g. gitolite.) However gitolite doesn't really support PRs > > in a uniform way and so CI is mostly for submitted code; similar to > > the existing ::gentoo repo CI offered by mgorny. > > > > If we build a code review solution (like gitea / gerrit) would people > > use it? Would you use it if you couldn't merge (because the code > > review solution can't gpg sign your commits or merges) so a tool like > > the existing pram tool would be needed to merge? > > > > -A > > > > [0] Mostly arzano, if I'm honest. I am just the point-y haired > > manager in this effort. > > There are several CI systems that could be used. As for CI, my > experience has been with buildbot. It would be fairly straightforward > to integrate with the current gitolite/gitweb hosting. > It is also extremely flexible in its capabilities, although can be > difficult to master. It has a good web interface, but it can even be > run via it's API's using curses, python, bash,.... There is a > buildbot-travis plugin which is capable of running existing .travis file > configurations. It also extends its capabilities to include custom > buildbot step definitions. I have not packaged it yet for gentoo, but > it is on my todo list. One of buildbot's capabilities is the ability to > run tests/builds on multiple workers (different arches or whatever) > both in parallel or series. It could be made to integrate with our > bugzilla using the python client (pybugs was it?). > My understanding is that CI systems are all quite similar. We have configured gitlab-ci, drone, and zuul as tests and I am familiar with travis-ci and buildbot from other projects. I'm less concerned about this aspect tbh. I'm also not super concerned about packaging. E.g. for gitlab-runner (the worker portion of gitlab-ci) we just deploy upstream containers and don't package them in ::gentoo at all. Our onprem gitlab is a container solution; gitea is a container solution; our SSO IDP is a container solution; gerrit is currently a container solution. These don't bother me (too much, ugh zuul uses zookeeper? ugh.) The major differentiators for CI appear to be: - SCM support (we currently only really care about git compatible systems, but some contenders only support some providers.) - builders / workers (how do they deploy). For example gitlab has a container based work executor while zuul uses ansible; I suspect - Authentication (ideally should support SAML or openID so we can integrate with our alpha sso solution for Gentoo.) - The webUI; e.g is the solution horrible to use / interact with. Hard to say without a trial, IMHO. -A > > But that still leaves a PR/code review option. > > --000000000000387a6105a69cfe42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 27, 2020 at 1:09 AM Brian= Dolbec <dolsen@gentoo.org> = wrote:
On Tue, 2= 6 May 2020 20:24:56 -0700
Alec Warner <ant= arus@gentoo.org> wrote:

> The TL;DR is that a crack team of infra-folks[0] have been putting
> together demos of CI services and things like gitlab / gitea / gerrit<= br> > and so on.
>
> Some of these come in combined (e.g. gitlab offers repo hosting, code<= br> > review / pull reqs, CI services, and deploy services.) Some of these > are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea
> offers repo-hosting but CI is separate (e.g. drone.)
>
> On the infra-side, I think we are pretty happy with repo-hosting
> (gitolite) and repo-serving (gitweb). We are missing a CI piece and a<= br> > pull-request piece. Most of the users using PRs use either a gitlab > or github mirror.
>
> I think the value of CI is pretty obvious to me (and I see tons of use=
> cases in Infra.) We could easily build CI into our current repository<= br> > solution (e.g. gitolite.) However gitolite doesn't really support = PRs
> in a uniform way and so CI is mostly for submitted code; similar to > the existing ::gentoo repo CI offered by mgorny.
>
> If we build a code review solution (like gitea / gerrit) would people<= br> > use it? Would you use it if you couldn't merge (because the code > review solution can't gpg sign your commits or merges) so a tool l= ike
> the existing pram tool would be needed to merge?
>
> -A
>
> [0] Mostly arzano, if I'm honest. I am just the point-y haired
> manager in this effort.

There are several CI systems that could be used.=C2=A0 As for CI, my
experience has been with buildbot.=C2=A0 It would be fairly straightforward=
to integrate with the current gitolite/gitweb hosting.
It is also extremely flexible in its capabilities, although can be
difficult to master.=C2=A0 It has a good web interface, but it can even be<= br> run via it's API's using curses, python, bash,....=C2=A0 =C2=A0Ther= e is a
buildbot-travis plugin which is capable of running existing .travis file configurations.=C2=A0 It also extends its capabilities to include custom buildbot step definitions.=C2=A0 I have not packaged it yet for gentoo, but=
it is on my todo list. One of buildbot's capabilities is the ability to=
run tests/builds on multiple workers (different arches or whatever)
both in parallel or series.=C2=A0 It could be made to integrate with our bugzilla using the python client (pybugs was it?).
My understanding=C2=A0is that CI systems are all quite similar.= We have configured gitlab-ci, drone, and zuul as tests and I am familiar w= ith travis-ci and buildbot from other projects. I'm less concerned abou= t this aspect tbh. I'm also not super concerned about packaging. E.g. f= or gitlab-runner (the worker portion of gitlab-ci) we just deploy upstream = containers and don't package them in ::gentoo at all. Our onprem gitlab= is a container solution; gitea is a container solution; our SSO IDP is a c= ontainer solution; gerrit is currently a container solution. These don'= t bother me (too much, ugh zuul uses zookeeper? ugh.)

<= div>The major differentiators for CI appear to be:
=C2=A0- SCM su= pport (we currently only really care about git compatible systems, but some= contenders only support some providers.)
=C2=A0- builders / work= ers (how do they deploy). For example gitlab has a container based work exe= cutor while zuul uses ansible; I suspect=C2=A0
=C2=A0- Authentica= tion (ideally should support SAML or openID so we can integrate with our al= pha sso solution for Gentoo.)
=C2=A0- The webUI; e.g is the solut= ion horrible to use / interact with. Hard to say without a trial, IMHO.

-A
=C2=A0

But that still leaves a PR/code review option.

--000000000000387a6105a69cfe42--