On Tue, Oct 24, 2017 at 9:59 AM, Fabian Arrotin arrfab@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