[almighty] using ci.centos.org for ALM

[Karanbir Singh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

> When I did JBoss Tools I did not accept letting JBoss Jenkins user
> have full access since it meant being okey that /anyone/ by
> accident could nuke our repositories if they had access to
> Jenkins.
> 
> https://www.reddit.com/r/programming/comments/1qefox/jenkins_developer
s_accidentally_do_git_push_force/
>
>  so yeah, for now we don't have much to loose - but something to
> consider how to handle better going forward.
> 
> /max http://about.me/maxandersen
> 

regards

- -- 
Karanbir Singh, Project Lead, The CentOS Project, London, UK
Red Hat Ext. 8274455 | DID: 0044 207 009 4455
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXuvCfAAoJEI3Oi2Mx7xbtXogIAMxVndFyg6ORSuSZpXItbG8e
eQOdl8hfgtDAhB8BTfcUn3+GBb7jMQDNrtr90K3BqdZjBo4kx5MwKNfojrJ9Ct8+
O6CUBU4ZvnEho5YGo+sJEAKhqNCPkpeMYe6/UdI7NfJWlN+JnBsPc0hSsO98a91U
uE3aaqkOv0MEHyuGS9hjnPeM0Bq5rX8IrDOBrNRVUxPeJb9anBhxE1G0YaIp4CYw
KRi+uOU3b2kPzwItZy9Nd5ADk9ldOhd7nqZx2Ns5T+eQKYLl2eoyLTr8MhfcclyI
qlctiDTyuQJcfFU1XoJysYhQNdk5hwJESlMDffcXbsIFPGu27X6CmmJyr+tyoGY=
=DGEh
-----END PGP SIGNATURE-----