Project

General

Profile

Bug #7182

Identical branch HEADs can result in Vagrant building from the wrong branch

Added by anonym over 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Build system
Target version:
Start date:
05/09/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

It's expected that Vagrant's rake build starts a build from the checked out branch. However, if the current commit doesn't have a unique symbolic reference there's no guarantee the expected branch is built. For instance, for branches that just update the corresponding APT suite (and hence have empty deltas against devel) Vagrant may decide to build from devel instead, so the updates in the APT suite are not used.

The reason is the way we try to restore the branch name from the current commit using git symbolic-ref in build-tals. We should instead explicitly pass the checked out branch name or tag (and perhaps provide a TAILS_BUILD_OPTION called branch=<branch-or-tag-name> to allow specifying it explicitly) that then is passed to build-tail in our Rakefile.

Associated revisions

Revision a6aa7504 (diff)
Added by anonym over 3 years ago

Re-fetch tags when running build-tails with Vagrant.

That should fix an annoyance related to #7182 that I frequently
encounter: when I, as the RM, rebuild the release image the second
time from the force-updated tag, the build system would not have the
force-updated tag.

Refs: #7182

History

#1 Updated by anonym over 5 years ago

  • Target version changed from Tails_1.1 to Hole in the Roof

Don't think I'll have time to fix this in time for 1.1. Let's call it a Hole in the Roof, since it only affects Tails developers that can push stuff to our APT repo, and it seems I'm the only one that actually uses Vagrant among us.

#2 Updated by intrigeri over 5 years ago

Sorry if I'm overly naive and missing the point, but... when we've (hopefully correctly) detected that we are building from a branch, can't we just initialize GIT_BRANCH in the same way as it's done in auto/scripts/tails-custom-apt-sources, that is with trivial git branch | awk ... trickery?

We could even use the same logic as tails-custom-apt-sources uses to detect wether we should be building from a tag or not: using different logics, and implementations, for these two scripts, is prone to the kind of mismatch we're experiencing here. Both scripts are supposed to detect and sort apart the exact same set of situations, right?

#3 Updated by kytv about 5 years ago

anonym wrote:

Don't think I'll have time to fix this in time for 1.1. Let's call it a Hole in the Roof, since it only affects Tails developers that can push stuff to our APT repo, and it seems I'm the only one that actually uses Vagrant among us.

FWIW I've been bitten by this and I also use Vagrant. It's quite convenient. (Of course, I don't have push rights either).

When I'm working in a branch of my own creation (let's say feature/some-feature) the build can't be done because

auto/scripts/tails-custom-apt-sources
will output an apt-sources line for a repository that doesn't exist--it's my branch and deb.tails.boum.org doesn't and shouldn't have a deb repo for my feature branch, some-feature.

For this reason I may want to create a new branch outside of feature/ which will only be on my local box, to prevent adding the file containing a reference to the non-existent repo.

So in the meantime, in my temporary, local-only branch I will apply the following and check it in, making sure that my branch will be used.


-if on_topic_branch; then
-       output_apt_binary_source "$(branch_name_to_suite $(current_branch))" 
-fi

#4 Updated by intrigeri about 5 years ago

So in the meantime, in my temporary, local-only branch I will apply the following and
check it in, making sure that my branch will be used.

Another option would be to locally merge your branch into stable or devel (depending on where it's supposed to be merged) and build from there.

#5 Updated by kytv about 5 years ago

What I've started doing is working entirely outside of feature/* then moving it back to feature/ when I'm ready to have more eyes on it. This way the non-existent apt repository source file isn't created and the squashfs creation defaults to compressing with gzip.

So far this "workflow" is working out OK.

#6 Updated by anonym over 3 years ago

  • Target version changed from Hole in the Roof to Tails_2.3

#7 Updated by anonym over 3 years ago

  • Target version changed from Tails_2.3 to Tails_2.4

Just some random notes:

  • now, when there is no more branches that doesn't encode changes of APT suite in Git, the problem is mostly not relevant
  • there is one instance of this which I frequently encounter (but can easily deal with manually), and this is that when I rebuild the each release the second time from the force-updated tag -- our current implementation does not fetch tags, but likely that is fixed simply by:
--- a/vagrant/provision/assets/build-tails
+++ b/vagrant/provision/assets/build-tails
@@ -74,7 +74,7 @@ else
        fi
        test -d "$WORKSPACE" || git clone /amnesia.git "$WORKSPACE" 
        cd "$WORKSPACE" 
-       git fetch origin
+       git fetch --tags origin
 fi

 if [ "$TAILS_RAM_BUILD" ]; then

So, perhaps we can just push that last tiny change, and forget about this. I'll try to make time to check intrigeri's suggestion first, though.

#8 Updated by intrigeri over 3 years ago

  • now, when there is no more branches that doesn't encode changes of APT suite in Git, the problem is mostly not relevant

Indeed, the way I get it that's a non-issue nowadays.

  • there is one instance of this which I frequently encounter (but can easily deal with manually), and this is that when I rebuild the each release the second time from the force-updated tag -- our current implementation does not fetch tags, but likely that is fixed simply by: [...]

So, perhaps we can just push that last tiny change, and forget about this.

Yes.

I'll try to make time to check intrigeri's suggestion first, though.

Only if you think it's worth the additional effort :)

Beware, though: tails-custom-apt-sources will be modified quite a bit for #10748, that really needs to go into Tails 2.4

#9 Updated by anonym over 3 years ago

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (anonym)

intrigeri wrote:

  • now, when there is no more branches that doesn't encode changes of APT suite in Git, the problem is mostly not relevant

Indeed, the way I get it that's a non-issue nowadays.

Given this...

  • there is one instance of this which I frequently encounter (but can easily deal with manually), and this is that when I rebuild the each release the second time from the force-updated tag -- our current implementation does not fetch tags, but likely that is fixed simply by: [...]

So, perhaps we can just push that last tiny change, and forget about this.

Yes.

... and that I pushed this (a6aa750) => closing.

I'll try to make time to check intrigeri's suggestion first, though.

Only if you think it's worth the additional effort :)

Beware, though: tails-custom-apt-sources will be modified quite a bit for #10748, that really needs to go into Tails 2.4

Right. Let's not bother.

#10 Updated by anonym over 3 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF