[3.1.107-SDK] git error near end of building source tarball

[cerebrate]

Shortly after the download of https://dotnetcli.azureedge.net/source-built-artifacts/assets/Private.SourceBuilt.Artifacts.0.1.0-3.1.106.tar.gz, the build fails with the error:

  fatal: invalid reference: HEAD
/home/avatar/src/source-build-3.1.107-SDK/eng/SourceBuild.Tarball.targets(46,5): error MSB3073: The command "git --work-tree="/home/avatar/src/source-build-3.1.107-SDK/artifacts/source-tarball/" checkout HEAD -- src" exited with code 128. [/home/avatar/src/source-build-3.1.107-SDK/packages/restored/microsoft.dotnet.arcade.sdk/1.0.0-beta.19359.6/tools/Build.proj]

Tested with target directories within and without the source tree, previously existing and not; the same result persists.

[dagood]

How did you get the sources? (And I'm assuming you're still on Debian 11/bullseye under WSL from #1716?)

It sounds like you're probably using the GitHub-provided tar.gz/zip, which are not exercised in CI but we can't disable GitHub showing them everywhere. 😕 More info at #1646. The reason I think this is what you're hitting is that git init; git checkout HEAD -- src in a blank dir gives me the same error you ran into.

We recently added a quick workaround so they work with ./build.sh, but I don't think I tried them with ./build-source-tarball.sh:

source-build/build.sh

Lines 34 to 42 in cf4ce12

	# If .git doesn't exist at the repo root, create it. It's required for the build to work. The very
	# prominent source tar.gz and zip files created by GitHub don't include it, so it's worth having a
	# fallback here. See https://github.com/dotnet/source-build/issues/1646 for details.
	if [ ! -e "$scriptroot/.git" ]; then
	(
	cd "$scriptroot"
	git init
	)
	fi

You should use Git to get your sources for now if you want the smoothest experience. But if this is what's going on, we can have this issue track getting ./build-source-tarball.sh working.

Maybe we could add something like git add -A . && git commit -m 'workaround' to the workaround to get this working. If you'd like to try that out and submit a PR for that or something similar, I think it'd be fine to merge to unblock this scenario.

[cerebrate]

I tried two sources, one of which was the github .tar.gz from the releases page (as in the case of the messages quoted above), but I've also tried a git clone of this repo, release-3.1 branch, and had the same issue.

I'll give it another try with the workaround tonight and see what I get.

[dagood]

but I've also tried a git clone of this repo, release-3.1 branch, and had the same issue.

This should work fine, it's what we test in CI on Debian 9, which should be close enough: https://dev.azure.com/dnceng/public/_build/results?buildId=771154&view=logs&j=9030a8ca-671a-5e0a-1ac4-e5aba92dfe8b&t=15ec4aa2-dea6-5467-a7f9-48e39992b810
(Slightly different steps, but goes through the same general process, and I wouldn't expect our local builds on various other Linuxes to be any different when it comes to this command.)

I'd strongly recommend not using the .tar.gz--stick with Git to avoid this known problem area. The git init workaround doesn't run at all if you have a proper Git repo set up, so I wouldn't bother looking at that until you know the build works otherwise.

Can you find . -iname '*.binlog' (https://aka.ms/binlog) and send them if you can? One missing piece here is what the working directory is for that particular git command, and the binlog would have that.

You could also check the contents of .git, try git log, git checkout HEAD -- src, etc. to try to figure out if you have a corrupted repo in some way. Seems unlikely though, not sure how that would result in that error.

[dseefeld]

@cerebrate Any info on this? Is this continuing to fail for you?

[cerebrate]

I've got it working, but not in a terribly useful way -- for debugging purposes, that is.

Which is to say, it was failing (the git version, not the .tar.gz, which consistently fails) right up until it wasn't, and the only thing that changed at the appropriate time was the updating and restarting of a local NFS server which, in theory, had nothing at all to do with the build (all the build folders, etc., were local, and so forth), which leaves me in the rather unhelpful situation of having to say "it works now, but I have no idea why" .) 😦 🤷

[dagood]

Hmm... well, from my perspective, the simplest explanation is that you ran a build on a GitHub tar.gz while thinking it was on a Git clone, and when you tried again, it was actually the first time trying it with a Git clone. No idea how likely that is given your setup/process, but it seems to be a pretty specific error that we can't repro without the GitHub tar.gz.

If you (or anyone) hits this again with a Git clone, please share the binlogs and more info, and don't clean up the repo so we can do more deep investigation. Would be happy to reopen the issue then and dig deeper into this.