Re: CI behaving differently from local tests

From: Bence Ferdinandy <bence@ferdinandy.com>
Date: Oct 18, 2024, 22:32 UTC
Message-ID: <D4ZAELFWJMKN.S88LJ6YK31LZ@ferdinandy.com>
In-Reply-To: <D4YDINQ682QL.N0FD2J9C1O22@ferdinandy.com>

On Thu Oct 17, 2024 at 22:45, Bence Ferdinandy <bence@ferdinandy.com> wrote:

Show 69 quoted lines

> 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

-- 
bence.ferdinandy.com