Page MenuHomePhabricator

Install Jenkins Job Builder on gallium
Closed, DeclinedPublic

Description

Jenkins Job Builder need to be deployed on Gallium so we can automatically update Jenkins jobs configuration whenever the builder config has been updated.

https://gerrit.wikimedia.org/r/#/c/24620/


Version: unspecified
Severity: enhancement

Details

Reference
bz43141

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:48 AM
bzimport set Reference to bz43141.
bzimport added a subscriber: Unknown Object (MLST).

Paul Belanger has a Debian directory to build a Debian package at : https://github.com/pabelanger/jenkins-job-builder-deb . So might end up building a deb package and deploy that instead of the above change.

Pinged Paul, v0.3.0 is already in Ubuntu raring. He is currently working on package v0.4.0.

Note that a Debian package may not be feasible.

jenkins-job-builder is under active development, and it is only used to convert the YAML files to XML files. One they are XML they are pushed to the Jenkins API. It is a relatively small tool.

The current process for deploying jenkins configuration is:

  • Install jenkins-job-builder locally (every time)
  • Run jenkins-job-builder to build the XML files from YAML templates
  • Run jenkins-job-builder to push them to Jenkins over HTTP

Since jenkins-job-builder changes frequently, we just re-run "python setup.py" before we upgrade because we constantly add features to it and start using them immediately.

So unless someone is going to re-build the package, push to out apt repo and deploy on gallium on average *one a week*, this is not a solution. In other words, don't waste doing it, because we will not use it in that case.

Timo, that will use a Debian package. If we need the package to be upgraded every single day that will happen :-]

Please do not install JJB on gallium until it is packaged.

lcarr wrote:

Krinkle - I think your comment is a compelling reason to have resources for an easier package building system. I don't think that running setup.py on production hosts is a good idea (i know we already do it for some things... which makes me unhappy). Having a script pull down code from an external repository is just asking for more security issues

hashar: You assigned this issue to yourself 14 months ago.
Could you please provide a status update and inform us whether you are still working (or still plan to work) on this issue?
In case you do not plan to work on this issue anymore, should the assignee be set back to default and the bug status changed from ASSIGNED to NEW/UNCONFIRMED? Thanks!

Unassigning. That is a low priority so might do it one day but nothing urgent for now. I will get it installed on labs instance instead of having to use a Debian package.

Thx Andre!

hashar claimed this task.

For now on we deploy them manually. Maybe we will get that moved to use scap3 and have it generate the jobs directly from the Jenkins master.