[CentOS-devel] CERN pre-dojo meeting topic : Sig request for sig specific git

[George Dunlap]

On Tue, Oct 24, 2017 at 9:59 AM, Fabian Arrotin <arrfab at centos.org> wrote:
> <paste>
> sigs would like to use centpkg / lookaside, build direct through git to koji
> authentication requirements to accounts.centos.org
> Fabian to evaluate git solutions and report back to sig chairs.
> mrunge has volunteered to be the "guinea pig" of the new system
> </paste>
>
> So let's start the thread, to be sure that all involved people would be
> able to comment.
> SIGs would like to start building from git, and not from SRPMs they have
> to create/upload themselves.
>
> For GIT itself, several options exist :
> - using git.centos.org : that would mean SIG would need access to
> specific repositories and also a "lookaside cache" feature to not store
> binary blogs/tarballs in git itself. And that would also need an
> authentication backend that the current solution would need to be tied to
>
> - using github : most people have probably a GH account, so everything
> can be hosted there, and for the "lookaside cache", Github has LFS
> support built-in so that would need
> re-tooling correctly centos-packager to use that (but no rpm yet for
> git-lfs client side). Problem would be suddenly that we only rely on GH
> to build packages/artifacts on cbs.centos.org
>
> - using other "on premise" git solution , close to the CBS builders :
> from my quick research, I'll probably have a look at gitlab, but gitea
> was on my radar and it implements natively :
>   - LFS support (so "lookaside" cache without having to write an app for
> that, and so using directly also the repo ACL to let people store
> tarballs/blobs
>   - openid/oauth2 support (so we can then also reuse
> https://accounts.centos.org, through https://id.centos.org IdP
>
> Waiting for comments/input/feedback on those points

>From our discussion, I remember that with the "lookaside cache", it
should be possible for a "drive-by" contributor to submit a change
which included a new tarball, by submitting a pull request that had
the proper hash; I could then download the tarball from the upstream
website myself, verify the hash, and upload it to the lookaside cache
when merging the PR.

For an on-prem gitlab with lfs support, would it be possible for
"drive-by" contributors to send changes which changed tarballs in a
similar way?

FWIW my preference would be:
* On-prem git solution with git-LFS, probably gitlab
* github + lookaside cache
* git.centos.org + traditional look-aside cache
* github + LFS support

 -George