Merge lp:~ce-infrastructure/capomastro/capomastro-jenkins-exposure-1155 into lp:capomastro
Status: | Merged |
---|---|
Approved by: | Daniel Manrique |
Approved revision: | 154 |
Merged at revision: | 141 |
Proposed branch: | lp:~ce-infrastructure/capomastro/capomastro-jenkins-exposure-1155 |
Merge into: | lp:capomastro |
Diff against target: |
218 lines (+75/-3) 10 files modified
capomastro/local_settings.py (+1/-2) debian/changelog (+7/-0) projects/templates/projects/dependency_detail.html (+1/-0) projects/templates/projects/dependency_form.html (+1/-0) projects/templates/projects/missing_archiver_alert.html (+4/-0) projects/templates/projects/project_detail.html (+1/-0) projects/templates/projects/project_form.html (+1/-0) projects/templates/projects/projectbuild_detail.html (+1/-1) projects/tests/test_views.py (+21/-0) projects/views.py (+37/-0) |
To merge this branch: | bzr merge lp:~ce-infrastructure/capomastro/capomastro-jenkins-exposure-1155 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Sheila Miguez (community) | Approve | ||
Daniel Manrique (community) | Approve | ||
Review via email: mp+242412@code.launchpad.net |
Description of the change
This is part of a task to story 1155 about investigating whether we need to expose Jenkins for real or not. If this merge is accepted I think it's fairly safe to commit and push directly the following change to the deploy branch of Capomastro, too:
=== modified file 'deploy.sh'
--- deploy.sh 2014-11-13 02:51:13 +0000
+++ deploy.sh 2014-11-19 21:52:22 +0000
@@ -43,5 +43,4 @@
juju add-relation apache2:
# Expose web services
-juju expose jenkins
juju expose apache2
The tl;dr of these commits is: we don't need to overexpose Jenkins really, but some warning to the users about not having an archiver setup is good since the archiver is the one which would replace the Jenkins URLs so users can download artifacts.
I made an inline comment, plus I notice there are no tests for this and I'm wondering if it's worth somehow testing it. Perhaps checking that the context has no "archive" value, then creating an Archive and checking again, this time that the context has the archive attribute.
I found a possibly related snippet in archives/ tests/test_ helpers. py, that may prove helpful.
It may also be possible to do a test where we actually verify that the rendered template has the warning string if there's no archive.
Apologies if this is vague, it's just showing my incomplete knowledge of django templates and testing :/