| Message ID | D4YDINQ682QL.N0FD2J9C1O22@ferdinandy.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | CI behaving differently from local tests | expand |
On Thu Oct 17, 2024 at 22:45, Bence Ferdinandy <bence@ferdinandy.com> wrote: > Hi, > > I'm looking at why the set-head series (cf.: > https://lore.kernel.org/git/20241014225431.1394565-1-bence@ferdinandy.com/) > breaks the CI. The problem stems from the local test repositories being set up > differently from that of the CI. > > I ran both the CI and a local test on current master with the following patch > applied on top, i.e. I print all remote refs and intentionally break the test > so that the result is easy to get from the CI: > > diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh > index 532035933f..d625a3a8b6 100755 > --- a/t/t5505-remote.sh > +++ b/t/t5505-remote.sh > @@ -724,8 +724,11 @@ test_expect_success 'update' ' > cd one && > git remote add drosophila ../two && > git remote add apis ../mirror && > + git ls-remote drosophila && > + git ls-remote apis && > git remote update && > git branch -r >output && > + echo "force error" >output && > test_cmp expect output > ) > ' > > The CI gives the following output: > https://github.com/ferdinandyb/git/actions/runs/11392309625/job/31698105287 > > > + git ls-remote drosophila > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > + git ls-remote apis > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 HEAD > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > > > While from ./t5505-remote.sh -v I get: > > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > > Since `git remote update` here is essentially running `git fetch --multiple --all`, > with the set-head series applied we're attempting to set HEAD for both > remotes. Obviously, this fails locally and succeeds in the CI, which is > actually the patch series behaving as intended, but obviously a drift between > the local and the CI testing environments. > > I'm probably too tired right now, but I don't see how or what could make the > mirror repo be different depending on having it locally or in the CI ... At > least I know it's definitely not my patch series :) Does anyone have an idea > what to try and look into? > > I guess ideally the fix for this would be added to the beginning of the series > so we can continue with both local and CI tests working. (Although it could be > marked as a know breakage as well, not so elegant). > > Thanks, > Bence I found the issue. It comes down to the CI running with export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main while this not being set in ./t5505-remote.sh. Now the bandaid here is adding this to t5505, but it may not be the solution. The problem essentially is that `git remote add --mirror -f origin [somerepo]` does not update HEAD in a bare repository. Consider the following: git config --global init.defaultBranch mypreference mkdir one cd one git init -b notmypreference git commit -m "initial commit" --allow-empty cd .. mkdir mirror cd mirror git init --bare git remote add --mirror -f origin ../one cat HEAD You'll see HEAD is ref: refs/heads/mypreference. Continuing cd .. mkdir r_one cd r_one git init git remote add origin ../mirror git ls-remote We arrive at a single reference pointing to refs/heads/notmypreference. If we do the same exercise, but instead setting up repo "one" with `git init -b mypreference` running ls-remote "r_one" will actually also yield a HEAD reference. I'm not sure if it should or not, so for now I'll just make sure that ./t5505-remote.sh uses "main" as the default branch. Best, Bence
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 532035933f..d625a3a8b6 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -724,8 +724,11 @@ test_expect_success 'update' ' cd one && git remote add drosophila ../two && git remote add apis ../mirror && + git ls-remote drosophila && + git ls-remote apis && git remote update && git branch -r >output && + echo "force error" >output && test_cmp expect output ) '
Hi, I'm looking at why the set-head series (cf.: https://lore.kernel.org/git/20241014225431.1394565-1-bence@ferdinandy.com/) breaks the CI. The problem stems from the local test repositories being set up differently from that of the CI. I ran both the CI and a local test on current master with the following patch applied on top, i.e. I print all remote refs and intentionally break the test so that the result is easy to get from the CI: The CI gives the following output: https://github.com/ferdinandyb/git/actions/runs/11392309625/job/31698105287 + git ls-remote drosophila 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side + git ls-remote apis 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 HEAD 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side While from ./t5505-remote.sh -v I get: 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side Since `git remote update` here is essentially running `git fetch --multiple --all`, with the set-head series applied we're attempting to set HEAD for both remotes. Obviously, this fails locally and succeeds in the CI, which is actually the patch series behaving as intended, but obviously a drift between the local and the CI testing environments. I'm probably too tired right now, but I don't see how or what could make the mirror repo be different depending on having it locally or in the CI ... At least I know it's definitely not my patch series :) Does anyone have an idea what to try and look into? I guess ideally the fix for this would be added to the beginning of the series so we can continue with both local and CI tests working. (Although it could be marked as a know breakage as well, not so elegant). Thanks, Bence