Merge lp://staging/~juju-qa/charms/precise/jenkins-slave/trunk into lp://staging/charms/jenkins-slave
| Status: | Merged |
|---|---|
| Merged at revision: | 13 |
| Proposed branch: | lp://staging/~juju-qa/charms/precise/jenkins-slave/trunk |
| Merge into: | lp://staging/charms/jenkins-slave |
| Diff against target: |
143 lines (+79/-29) 4 files modified
README.md (+23/-0) hooks/install (+48/-21) hooks/install.d/README.md (+7/-7) metadata.yaml (+1/-1) |
| To merge this branch: | bzr merge lp://staging/~juju-qa/charms/precise/jenkins-slave/trunk |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Charles Butler (community) | Approve | ||
|
Review via email:
|
|||
Description of the change
These changes allow jenkins-slave charm to be deployed to trusty and utopic.
Jenkins was removed from Ubuntu trusty. It is not possible to install jenkins from Ubuntu archives on trusty.
I need to deploy trusty jenkins-slaves into closed networks. I cannot install the slave via PPA.
I also intend to relate the trusty jenkins-slave to a precise jenkins master.
Jenkins as a sordid history of introducing incompatibilities with previous version. A small version change can prevent a slave from talking to a master or break hundreds of plugins. I choose to include the precise jenkins-slave package in the charm to ensure this charm is compatible with the only master jenkins a user can deploy (a precise one).
I refactored install to make it easier to read and more robust.
You don't have to accept this, but since I have a queue of people wanting this charm, mine will be the one used in the wild, and by other Canonical divisions :)
| Curtis Hovey (sinzui) wrote | # |
Greetings,
I've had a chance to review this great jenkins slave submission! I do have a few nit picks with commentary on how to improve, they are as follows:
The README, while now being present - is still extremely light on details. It would be nice to cover all the basics of a readme. If you have the charm-tools package installed, issue 'charm add readme' and fill out the pertinent portions of the readme that effect the jenkins-slave charm complete with but not limited to:
- Configuration
- Upstream Details on where to file bugs/ how to contact the maintainer
- adding the details from hooks/install.d into the main README
- Adding details on how to provide a newer DPKG than whats packaged in the charm
In the metadata.yaml, where James Page is still the listed maintainer. Is the Juju QA team taking over the Jenkins Charm suite? If so, it would be brilliant if you could set the QA team as the maintainer of the charm in the metadata.
While I like the concept of fat charms and using the deb packaged within the charm itself, it would be another great addition to add the option for installation from a PPA - such as outlined here: https:/
All in all this is a great submission. I deployed 3 nodes, everything seems to be in order.
Thank you for a great submission! I look forward to seeing future contributions.