Opened 6 months ago

Closed 5 months ago

#29572 closed defect (fixed)

Fetching latest commits fails when building testbuilds

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/rbm Version:
Severity: Normal Keywords: tbb-rbm, TorBrowserTeam201903R
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Trying to build a test build on one of my build machines surprisingly failed during the fetch step with the following error:

./rbm/rbm build release --target testbuild --target torbrowser-windows-i686
fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
Error: Error fetching git repository
Makefile:117: recipe for target 'testbuild-windows-i686' failed

Instrumenting rbm showed me that this happens when git is trying to fetch the latest commits for the tor repo but there aren't any new ones. I compared the rbm config etc. with one of my other build machines where this issue does not show up and the only difference I found so far is the git version. On the succeeding machine I have 2.11.0 and on the failing one 2.1.4.

So, I am assuming right now that something between those versions got fixed in git that made the error go away. We should (a) figure out whether that theory is correct and, if so, (b) think about whether we want to support the older git versions affected by this and, if so, (c) think about a good workaround.

Child Tickets

Change History (16)

comment:1 Changed 6 months ago by boklm

The issue seems to be that we are on a branch while we do the git fetch.

But we are supposed to do a git checkout --detach when we are on a branch:

        my ($ref, undef, $success) = capture_exec('git', 'symbolic-ref', 'HEAD');
        chomp $ref;
        if ($success && -e ".git/$ref") {
            system('git', 'checkout', '-q', '--detach') == 0
                || exit_error "Error running git checkout --detach";
        }

Maybe the test to see if we are on a branch is not working?

To check that, you can go to the directory git_clones/tor and run:

 git symbolic-ref HEAD

And check that the output from this command exist in .git.

comment:2 Changed 6 months ago by boklm

I have also been doing some builds using git 2.1.4 (from Debian Jessie), and did not have this issue. So I am not sure it is related to the git version.

comment:3 in reply to:  1 Changed 6 months ago by gk

Replying to boklm:

Maybe the test to see if we are on a branch is not working?

To check that, you can go to the directory git_clones/tor and run:

 git symbolic-ref HEAD

And check that the output from this command exist in .git.

I get refs/heads/master and .git/HEAD shows ref: refs/heads/master.

comment:4 Changed 6 months ago by gk

Summary: Fetching latest commits fails with older git versions when building testbuildsFetching latest commits fails when building testbuilds

Okay, this happens with 2.11.0 as well.

comment:5 Changed 6 months ago by gk

So, doing the git checkout -q --detach manually in the tor repo helps. Now, the question is how I could have landed in that buggy state...

comment:6 Changed 6 months ago by gk

Resolution: worksforme
Status: newclosed

Hm, can't reproduce that anymore. :/ \o/

comment:7 Changed 5 months ago by boklm

Resolution: worksforme
Status: closedreopened

The nightly build machine is having the same issue:

Fetching commits for tor
fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
Error: Error fetching git repository
Makefile:179: recipe for target 'fetch' failed

comment:8 Changed 5 months ago by boklm

After going to the git_clones/tor directory and running git branch, I saw that HEAD was detached:

* (HEAD detached at tor-0.4.0.2-alpha)

And then after running ./rbm/rbm fetch tor, the issue was gone.

So I'm not sure what fixed it. Maybe the repository was in some strange state that was fixed by git branch?

comment:9 Changed 5 months ago by gk

OKay, I have a machine again where I can see the issue and one where not. If I go to git_clones/firefox and do a git status both show

On branch tor-browser-60.5.1esr-8.5-1
nothing to commit, working tree clean

However, looking at .git/refs/heads on the broken one just shows:

tor-browser-24.5.0esr-1      tor-browser-31.4.0esr-4.5-1
tor-browser-24.6.0esr-4.x-1  tor-browser-31.5.0esr-4.5-1
tor-browser-24.7.0esr-4.x-2  tor-browser-38.1.0esr-5.0-1
tor-browser-24.8.0esr-4.x-1  tor-browser-38.1.0esr-5.x-1
tor-browser-31.3.0esr-4.5-1  tor-browser-38.5.0esr-5.5-2

On the working one there are a ton of more branches and tor-browser-60.5.1esr-8.5-1 is among them.

comment:10 Changed 5 months ago by boklm

Could you run the following script from the git_clones/firefox directory?

#!/usr/bin/perl -w
use strict;
use IO::CaptureOutput qw(capture_exec);

my ($ref, undef, $success) = capture_exec('git', 'symbolic-ref', 'HEAD');
chomp $ref;
if ($success && -e ".git/$ref") {
    print "OK\n";
} else {
    print "ref: $ref\n";
    print "success: $success\n";
    print -e ".git/$ref", "\n";
}

This is doing the same check that rbm is doing before deciding to do a git checkout --detach, but might give some details if it doesn't work.

comment:11 Changed 5 months ago by gk

Perl does not like your line 12, but here is what I get:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "de_DE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
ref: refs/heads/tor-browser-60.5.1esr-8.5-1
success: 1
Use of uninitialized value in print at script line 12.

But, yes, as I said above there is no tor-browser-60.5.1esr-8.5-1. The question is why? Maybe that could happen if I manually point to a custom repo and a custom branch before somehow (I did that to test the patch for #29440). However, I don't remember doing so in the tor case and the nightly builds are probably not doing that either...

comment:12 Changed 5 months ago by boklm

Hmm, so your git repository is on a branch that does not have a corresponding file in .git/refs/heads.

The reason why we check that this file exists is that when we clone a git repository which does not have a master branch (such as tor-browser.git in the past), we are on a branch which does not exist, and git checkout --detach gives an error, so we want avoid running it.

What does git rev-parse --verify HEAD output in your git_clones/firefox repository? In the case of a repository without a master branch cloned, this gives an error. So if in your case it does not give an error, maybe we could use this command to check if we need to run git checkout --detach.

comment:13 Changed 5 months ago by gk

It gives the commit I am on, but both on the machine where the fetch is failing and where it is succeeding.

comment:14 Changed 5 months ago by boklm

Keywords: TorBrowserTeam201903R added
Status: reopenedneeds_review

In branch bug_29572 I made a patch that uses git rev-parse --verify HEAD to decide if git checkout --detach should be run:
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_29572&id=70d1ff3e7c1c5c69a1b4cdb61ee1b6b9e2a9bc4a

comment:15 Changed 5 months ago by boklm

Component: Applications/Tor BrowserApplications/rbm

comment:16 Changed 5 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good to me. Merged to rbm's master branch (commit 70d1ff3e7c1c5c69a1b4cdb61ee1b6b9e2a9bc4a) and picked up in tor-browser-build as well (commit 5a4f0853b634daa93e099ad613257f069635bb93).

Note: See TracTickets for help on using tickets.