[almighty] using ci.centos.org for ALM

[Pavol Pitonak]

Hi Karanbir,

what advantages does ci.centos.org have over current infrastructure? Why to
use JJB and not new Pipeline plugin?

Regards,
Pavol

On Mon, Aug 22, 2016 at 2:42 PM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 22 Aug 2016, at 14:31, Karanbir Singh wrote:
>
> > On 22/08/16 13:18, Max Rydahl Andersen wrote:
> >> With JJB, there are 2 types of jobs: 1) the service job that will
> >> typically run on schedule. This job will then parse the
> >> devtools-ci-index.git repo and setup jenkins jobs, change configs
> >> and notification details etc for the actual jobs. I think leaving
> >> that on a 10 min cron might be ok.
> >>
> >> I assume the reasons for 10 min cron vs building on change is to
> >> ensure manual edits in jenkins UI do not stay in effect by accident
> >> ?
> >
> > yeah - do not want anyone manually doing anything once the service job
> > has been run the first time. Also sometimes - based on the job time it
> > can take jenkins a bit of time to sync the configs through as well. So
> > its worth having the role/job get rebuilt in 10 min again to make
> > sure. Having said this, I've not seen a need for it in a while.
> >
> > The more pedantic(I like, if we can do this), is to have a JJB
> > validation job run on per-commit. So that when the service job kicks
> > in, its always going to work with a known good ( and locally
> > consumable.. JJB def ). This also helps validate that all plugins are
> > available, right version etc.
>
> sounds like a nice improvement if doable eventually - even better if
> possible
> to validate this in PR for the repo; but not sure if that validation
> will have side effects ?
>
> >> 2) the actual build jobs : I have a little PoC job there, let me
> >> try and adapt that for the almighty-core and demonstrate the
> >> github integration. We typically use the github webhooks to setup a
> >> notify task into jenkins rather than the other way around. This has
> >> quite a few advantages in that we can accept different kind of
> >> notify's and do different operations based on those - however, it
> >> does come with the downside that the ci-centos user needs to be
> >> added into the contributors for the git repos in github.com. If
> >> this isnt seen as a major problem, it would be the easiest, fastest
> >> path to take.
> >>
> >> We can add that if it is necessary - but is there any plans of
> >> having ci-centos have project specific users rather than global
> >> ci-centos users ?
> >
> > There is an action item to work with this, but looking through the
> > stack its not actually prioritised.  Let me try and see if we can vote
> > that up a bit.
>
> okey, cool - but as said, not a blocker. if giving ci-cents user access
> makes it move faster lets do it.
>
> You are admin on the repos now afaik so just do it if need be.
>
> /max
> http://about.me/maxandersen
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160822/b3e867d3/attachment.htm>