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@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@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@centos.org https://lists.centos.org/mailman/listinfo/ci-users