[almighty] using ci.centos.org for ALM

[Max Rydahl Andersen]

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