Feature #12616
Document our vagrant based build setup in Jenkins
100%
Description
Once we’ve finalized the deployment of the vagrant based build setup in Jenkins and have polished it so that it’s robust enough, we’ll have to move part of what is written in the blueprint in a design documentation.
Subtasks
History
#1 Updated by anonym 2017-09-28 18:29:17
- Target version changed from Tails_3.2 to Tails_3.3
#2 Updated by bertagaz 2017-10-17 13:47:27
- Status changed from Confirmed to In Progress
- Assignee changed from bertagaz to intrigeri
- % Done changed from 0 to 50
- QA Check set to Ready for QA
I’ve pushed two commits referencing this ticket that move some of the content from the blueprint to two different pages: contribute/build/vagrant for the generic parts, and contribute/working_together/roles/sysadmins/automated_builds_in_jenkins for what is specific to the deployment of Vagrant in Jenkins. How does it sound?
#3 Updated by intrigeri 2017-10-18 09:31:57
- Feature Branch set to master
#4 Updated by intrigeri 2017-10-18 10:05:53
- Assignee changed from intrigeri to bertagaz
Hi,
> contribute/build/vagrant for the generic parts
I think you mean contribute/build/vagrant-setup.
There’s a broken link on the first line of contribute/working_together/roles/sysadmins/automated_builds_in_jenkins. Again, please build & check the output locally before submitting for QA.
Taking a step back, it’s not obvious what “clean obsolete baseboxes” means. I suggest s/clean/delete/.
s/one copy of a basebox/one copy of a given basebox/ to remove some ambiguity.
“and would result in failures of subsequent builds” does not work grammatically speaking. I suggest making the subject of the verb explicit (and thus correct).
I don’t think “mountpoints” are a problem, but mounted filesystems are.
“For simplicity and security reasons, we are using nested virtualization”: I don’t think we have a strong case for simplicity here; I can see how one could argue this way, but it’s not obvious and not spelled out in the doc, so I suggest dropping the “simplicity” part.
“In our Jenkins setup we instead use” builds an opposition between something undefined and our Jenkins setup. Either specify what is that undefined other thing, or drop the comparison. Also, please point to the place where “use an existing, external apt-cacher-ng” is implemented for Jenkins builds. Finally, I don’t get how Feature #11979 has anything to do with the Jenkins setup.
In various places you mention using this or that Rake target; good. But I think this should link to the actual pieces of https://git-tails.immerda.ch/jenkins-jobs/ (or whatever relevant repo) where things are actually set up as described.
Dropping stuff from the “How we will make it happen” section of wiki/src/blueprint/reproducible_builds.mdwn has two problems:
- this text was our proposal for MOSS and I think it should remain there;
- you dropped “First of all” and left “Secondly”, which doesn’t work.
I could not find any place where we link to contribute/working_together/roles/sysadmins/automated_builds_in_jenkins so right now it’s not discoverable on our website (== well-hidden except for people who’ll find it by change in Git). Please take the PoV of the target audience (i.e. user-centric approach) when self-evaluating your work before sending for QA.
Is “The Vagrantfile shares the local clone of the Tails repository inside the basebox” correct? Or is this sharing only happening when we actually start a VM based on a build basebox? (I’m not 100% clear with the Vagrant terminology myself, sorry.)
#5 Updated by intrigeri 2017-10-18 10:06:32
- QA Check changed from Ready for QA to Dev Needed
#6 Updated by bertagaz 2017-10-19 16:14:40
- Assignee changed from bertagaz to intrigeri
- % Done changed from 50 to 60
- QA Check changed from Dev Needed to Ready for QA
intrigeri wrote:
> There’s a broken link on the first line of contribute/working_together/roles/sysadmins/automated_builds_in_jenkins. Again, please build & check the output locally before submitting for QA.
commit:a8bfc1ecbfdffda395e98080fa1df396f39a3fab
> Taking a step back, it’s not obvious what “clean obsolete baseboxes” means. I suggest s/clean/delete/.
commit:6c959022769327d6faf8c6e35b13695031dab4a7
> s/one copy of a basebox/one copy of a given basebox/ to remove some ambiguity.
commit:2dc498cbc5ee46c719e29fc0c3e867e9f5629878
> “and would result in failures of subsequent builds” does not work grammatically speaking. I suggest making the subject of the verb explicit (and thus correct).
>
> I don’t think “mountpoints” are a problem, but mounted filesystems are.
commit:bc7bf085e85bf239363c83ad84a6974ca38552e5
> “For simplicity and security reasons, we are using nested virtualization”: I don’t think we have a strong case for simplicity here; I can see how one could argue this way, but it’s not obvious and not spelled out in the doc, so I suggest dropping the “simplicity” part.
commit:bb8925b71076adf72a0067a5a549c1ce98c209cb
> “In our Jenkins setup we instead use” builds an opposition between something undefined and our Jenkins setup. Either specify what is that undefined other thing, or drop the comparison.
> Also, please point to the place where “use an existing, external apt-cacher-ng” is implemented for Jenkins builds. Finally, I don’t get how Feature #11979 has anything to do with the Jenkins setup.
commit:764289ed305b0d7443da617f0209d892f69923be
> In various places you mention using this or that Rake target; good. But I think this should link to the actual pieces of https://git-tails.immerda.ch/jenkins-jobs/ (or whatever relevant repo) where things are actually set up as described.
commit:b2ad965b1011f0403d9be968d63021a05d530403
> Dropping stuff from the “How we will make it happen” section of wiki/src/blueprint/reproducible_builds.mdwn has two problems:
>
> # this text was our proposal for MOSS and I think it should remain there;
> # you dropped “First of all” and left “Secondly”, which doesn’t work.
> I could not find any place where we link to contribute/working_together/roles/sysadmins/automated_builds_in_jenkins so right now it’s not discoverable on our website (== well-hidden except for people who’ll find it by change in Git). Please take the PoV of the target audience (i.e. user-centric approach) when self-evaluating your work before sending for QA.
commit:1604f6789288f22845b8cf14363286285c3dcaca
> Is “The Vagrantfile shares the local clone of the Tails repository inside the basebox” correct? Or is this sharing only happening when we actually start a VM based on a build basebox? (I’m not 100% clear with the Vagrant terminology myself, sorry.)
commit:4aa55151ba4bd3d26e113ab0c14a071c3c4632ce
#7 Updated by bertagaz 2017-10-19 16:48:33
> intrigeri wrote:
> > # this text was our proposal for MOSS and I think it should remain there;
> > # you dropped “First of all” and left “Secondly”, which doesn’t work.
Sorry, forgot this one. What about commit:fc94ebba87b438641fe0a2afa0cd6a575e5538bb ?
#8 Updated by intrigeri 2017-10-20 08:38:37
- Assignee changed from intrigeri to bertagaz
- % Done changed from 60 to 80
- QA Check changed from Ready for QA to Dev Needed
Thanks for fixing all these problems! I’ve pushed a bunch of other fixes and improvements => please review.
bertagaz wrote:
> > intrigeri wrote:
> > > # this text was our proposal for MOSS and I think it should remain there;
> > > # you dropped “First of all” and left “Secondly”, which doesn’t work.
>
> Sorry, forgot this one. What about commit:fc94ebba87b438641fe0a2afa0cd6a575e5538bb ?
That commit goes a bit further in treating our proposal as a working document that we can update incrementally. This could have been an option, but we didn’t do that so far, and doing it for one part of the implementation and not for the other bits is confusing. So I’d rather not do that at all => please revert our proposal to its original state. It’s fine if some text is duplicated between our original proposal and the final design doc. For extra clarify, again this comment of mine is only about the “How we will make it happen” section (some bit further down on the blueprint were WIP design documentation and it’s great that you moved it to a better place :)
#9 Updated by bertagaz 2017-10-20 09:25:08
- Assignee changed from bertagaz to intrigeri
- QA Check changed from Dev Needed to Ready for QA
intrigeri wrote:
> Thanks for fixing all these problems! I’ve pushed a bunch of other fixes and improvements => please review.
fine with me.
> bertagaz wrote:
> > Sorry, forgot this one. What about commit:fc94ebba87b438641fe0a2afa0cd6a575e5538bb ?
>
> That commit goes a bit further in treating our proposal as a working document that we can update incrementally. This could have been an option, but we didn’t do that so far, and doing it for one part of the implementation and not for the other bits is confusing. So I’d rather not do that at all => please revert our proposal to its original state. It’s fine if some text is duplicated between our original proposal and the final design doc. For extra clarify, again this comment of mine is only about the “How we will make it happen” section (some bit further down on the blueprint were WIP design documentation and it’s great that you moved it to a better place :)
commit:a7b83e8b
#10 Updated by intrigeri 2017-10-20 09:44:26
- Status changed from In Progress to Resolved
- Assignee deleted (
intrigeri) - % Done changed from 80 to 100
- QA Check changed from Ready for QA to Pass
LGTM, thanks!