So apparently there's "apps.ci.centos.org" which is an OpenShift v3 cluster - is there any more information on this available? I looked in https://wiki.centos.org/QaWiki/CI but didn't see much.
There's a lot of questions I have, but the main one is I'd like better hosting for https://github.com/projectatomic/papr which in particular includes our Homu instance that's critical path for several projectatomic repos - it gates our commits, so when it goes down, nothing goes into git.
Would it make sense to host this in apps.ci.centos.org?
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]
Our master and slaves are already integrated into apps.ci.centos.org and all the infrastructure and code is in[2]
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. I would happy to discuss it with you in more detail.
Thanks,
[1] https://mojo.redhat.com/videos/934601 [2] https://github.com/CentOS-PaaS-SIG/ci-pipeline/
-== @ri ==-
On Thu, Sep 28, 2017 at 4:38 PM, Colin Walters walters@verbum.org wrote:
So apparently there's "apps.ci.centos.org" which is an OpenShift v3 cluster - is there any more information on this available? I looked in https://wiki.centos.org/QaWiki/CI but didn't see much.
There's a lot of questions I have, but the main one is I'd like better hosting for https://github.com/projectatomic/papr which in particular includes our Homu instance that's critical path for several projectatomic repos - it gates our commits, so when it goes down, nothing goes into git.
Would it make sense to host this in apps.ci.centos.org? _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
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/030d2b1525a49c356210c18f57655afd9... 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?
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/030d2b1525a49c356210c18f57655afd9... 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
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
On Thu, Sep 28, 2017, at 03:38 PM, Colin Walters wrote:
So apparently there's "apps.ci.centos.org" which is an OpenShift v3 cluster - is there any more information on this available? I looked in https://wiki.centos.org/QaWiki/CI but didn't see much.
There's a lot of questions I have, but the main one is I'd like better hosting for https://github.com/projectatomic/papr which in particular includes our Homu instance that's critical path for several projectatomic repos - it gates our commits, so when it goes down, nothing goes into git.
This is still a pain point for us - any more information on whether apps.ci.centos.org is a good place for our Homu/PAPR infra?
On Nov 08 10:23, Colin Walters wrote:
On Thu, Sep 28, 2017, at 03:38 PM, Colin Walters wrote:
So apparently there's "apps.ci.centos.org" which is an OpenShift v3 cluster - is there any more information on this available? I looked in https://wiki.centos.org/QaWiki/CI but didn't see much.
There's a lot of questions I have, but the main one is I'd like better hosting for https://github.com/projectatomic/papr which in particular includes our Homu instance that's critical path for several projectatomic repos - it gates our commits, so when it goes down, nothing goes into git.
This is still a pain point for us - any more information on whether apps.ci.centos.org is a good place for our Homu/PAPR infra? _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
Let's get started with a project in apps.ci so you can poke around. New projects in apps.ci just need a bug created in bugs.centos.org (Project: Buildsys, Category: Ci.centos.org Ecosystem Testing) with the folks who should have access. Please be sure to include GPG keys so we can encrypt their credentials.
Cheers!
--Brian
On Mon, Dec 4, 2017, at 09:42 AM, Brian Stinson wrote:
Let's get started with a project in apps.ci so you can poke around. New projects in apps.ci just need a bug created in bugs.centos.org (Project: Buildsys, Category: Ci.centos.org Ecosystem Testing) with the folks who should have access. Please be sure to include GPG keys so we can encrypt their credentials.
-
Ari LiVigni -
Ari LiVigni -
Brian Stinson -
Colin Walters