[Ci-users] More info on apps.ci.centos.org?

[Ari LiVigni]

Colin,

This is pretty cool stuff and I agree with Biran it would be great to use
this generally in CentOS CI.
It seems this could also run in the Openshift environment as another layer
on top of the github Pull Requester.

Do you think this use case would work?

Thanks

-== @ri ==-
My PGP fingerprint is F87F1EE7CD8BEE13

On Thu, Sep 28, 2017 at 5:37 PM, Brian Stinson <brian at bstinson.com> wrote:

> On Sep 28 17:03, Colin Walters wrote:
> >
> >
> >
> > On Thu, Sep 28, 2017, at 04:50 PM, Ari LiVigni wrote:
> > > I don't know if this is what you are looking for, but we already are
> doing this without PAPR on PRs as part of the CI-Pipeline[1] in that same
> Openshift environment.
> > > We actually rebuild our own containers and validate them with our
> pipeline code in a stage pipeline before they get rolled into production.[1]
> >
> > Yep, that is cool!
> >
> > > I would like to avoid duplication of work if you guys are looking to
> the same thing and understand is there something that PAPR has over what we
> are currently doing for the ci-pipeline.
> >
> > Well there's two things conceptually; PAPR is a way to
> > test pull requests, but it's pretty integrated now into
> > our Homu instance, which adds quite a bit of logic
> > on top of github's default flow:
> > https://github.com/servo/homu/#why-is-it-needed
> >
> > And in particular for us, I personally really, really dislike merge
> commits
> > for single commit PRs.  It makes `git log` much harder to read.
> >
> > Compare e.g.:
> > https://github.com/ostreedev/ostree/commits/master
> > with your typical github project that uses merges;
> > we also have pretty stringent commit message requirements,
> > (IMO) comparable to Linux kernel core quality;
> > https://github.com/ostreedev/ostree/commit/
> 030d2b1525a49c356210c18f57655afd9f474b4f
> > is a good random example of a 2 paragraph explanation
> > for a 1 line change (written by a contributor matching our standards).
> >
> > Homu is definitely wedged awkwardly on top of github's
> > current review flow; there's no doubt we're "fighting"
> > github to an extent.  But the results for me are very
> > much worth it.
> >
> > I'm aware other people feel it's easier to just work with
> > whatever Github does by default; e.g. the
> > https://github.com/rhinstaller/anaconda/commits/master
> > project made that switch when they moved to Github.
> >
> > The Kubernetes (and OpenShift) projects use [Prow](http://prow.k8s.io/)
> > which hass some similar logic, although it generates merge
> > commits.
> >
> > There's some other discussion related to this here:
> > https://github.com/projectatomic/papr/issues/62
> >
> > I'm very interested in share at least some code though!
> > Having things in CentOS CI seems like a good start?
> >
> >
> > _______________________________________________
> > Ci-users mailing list
> > Ci-users at centos.org
> > https://lists.centos.org/mailman/listinfo/ci-users
>
> So in terms of the 'right place' for this, apps.ci is the place for
> doing persistent services in the CICO project, and I think we'd be happy
> to explore getting you folks in here.
>
> I'm wondering, though, if this papr+homu setup could be generalized so
> that other projects could benefit as well. I can see other projects
> needing a similar workflow for doing pre-merge cross testing, but
> integrated with the existing Jenkins tooling.
>
> --Brian
> _______________________________________________
> Ci-users mailing list
> Ci-users at centos.org
> https://lists.centos.org/mailman/listinfo/ci-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/ci-users/attachments/20170928/89028579/attachment.html>