merge_from_torbrowser-launcher_upstream Jenkins job is not testing what it should
The ISO build failures we see are about conflicts between our own patch and what's in Debian testing. We're testing merging upstream into our own branch.
Once this is fixed, we should revert commit 39158ca in our jenkins-jobs repo.
#2 Updated by intrigeri over 4 years ago
The initial goal was to give us a head start, during the sid->testing transition time, to realize we had to prepare for change. So perhaps this test should do exactly what our build system does, except it would
apt-get source torbrowser-launcher/sid instead of
/testing. This could be done in addition to what we already do (that is useful in itself, to detect even earlier upstream changes that'll break our stuff).
#6 Updated by intrigeri about 4 years ago
I'm starting to think that the problem is rather that we should maintain our profile as a fork of the upstream one, instead of as a fork of the one shipped in Debian: the changes applied in Debian are rarely relevant for us, and they should be upstreamed anyway. A Git submodule tracking our own torbrowser-launcher Git repo would be one way to do it: we would regularly merge upstream into that repo, Jenkins would tell us in advance when the merge would start failing, and at ISO build time we merely have to
cp the profile to the right place in the config tree.