[almighty] using ci.centos.org for ALM

[Max Rydahl Andersen]

On 22 Aug 2016, at 14:47, Pavol Pitonak wrote:

> Hi Karanbir,
>
> what advantages does ci.centos.org have over current infrastructure?

its resources controlled and managed by the devtools group under Carl 
Trieloff
so at least in theory we can more easily influence/upgrade it.

> Why to
> use JJB and not new Pipeline plugin?

JJB are used for bootstrapping the jenkins configuration - you can use 
it
to setup pipeline jobs[1] and more. They are when used this way 
complementary to each other.

Wether we continue to use it is an open question, but for now its the 
recommended way to setup jobs
on ci.centos.org.

[1] http://docs.openstack.org/infra/jenkins-job-builder/publishers.html

/max

>
> 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
>>




/max
http://about.me/maxandersen