git-artifacts: pipeline fails if existing_git_tag doesn't match the current version from mingw-packages

[dennisameling]

I ran this pipeline with the following variables:

EXISTING_GIT_TAG: v2.45.1.windows.1
BUILD_EXTRA_REV_FOR_EXISTING_GIT_TAG: 595592cd549f3653a46ab228e4c808eb571c5318

It then failed with these lines:

+ cd /usr/src/MINGW-packages/mingw-w64-git
+ cp PKGBUILD.v2.45.1.windows.1 PKGBUILD
+ test -z v2.45.1.windows.1
+ git update-index --ignore-submodules --refresh
mingw-w64-git/PKGBUILD: needs update
+ echo '::warning::Uncommitted changes after build!'
Warning: Uncommitted changes after build!
+ git diff
diff --git a/mingw-w64-git/PKGBUILD b/mingw-w64-git/PKGBUILD
index efc1026..dbe53ba 100644
--- a/mingw-w64-git/PKGBUILD
+++ b/mingw-w64-git/PKGBUILD
@@ -7,8 +7,8 @@ pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}"
 	 "${MINGW_PACKAGE_PREFIX}-${_realname}-doc-html"
 	 "${MINGW_PACKAGE_PREFIX}-${_realname}-doc-man"
 	 "${MINGW_PACKAGE_PREFIX}-${_realname}-test-artifacts")
-tag=2.45.0.windows.1
-pkgver=2.45.0.1.b5d0511969
+tag=2.45.1.windows.1
+pkgver=2.45.1.1.965b16798d
 pkgrel=1
 pkgdesc="The fast distributed version control system (mingw-w64)"
 arch=('any')
+ git bundle create /d/a/_work/git-for-windows-automation/git-for-windows-automation/artifacts/MINGW-packages.bundle 'main^..main'
fatal: ambiguous argument 'main^..main': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Error: Process completed with exit code 128.

I noticed that MINGW-packages is still on 2.45.0.windows.1, which partially explains where the error above comes from.

However, I'd expect the v2.45.1.windows.1 to build fine and not be dependent on the version that's currently in the MINGW-packages repo.

This workflow is quite complex and I'm not sure where to start looking in order to fix it. It does all kinds of fancy things like creating bundle_artifacts which is something I don't normally do in my daily Git workflows. If someone could give me some pointers, I'd be happy to update the workflow and test. Thanks!

[Alovchin91]

I might be completely wrong, but I think this happens because EXISTING_GIT_TAG is specified and thus there is no local main branch in the checkout.

If I understand correctly what this command does (I think it tries to create a .pack of the revision you’re trying to build), I think main here should probably be replaced with refs/tags/$EXISTING_GIT_TAG. So it becomes refs/tags/${EXISTING_GIT_TAG}^.. refs/tags/$EXISTING_GIT_TAG.

But I might be completely out of context here 😬

[dscho]

I just push the embargoed-builds branch that I used to generate v2.45.1's artifacts; I substantially revamped the way things work with existing tags, it's now more a branch-deployment model, where git-sdk-32, git-sdk-64, git, build-extra and MINGW-packages all have a, say, git-2.45.1 branch from which they build.

Speaking of MINGW-packages... I think I forgot to update that public main branch...

[dscho]

Speaking of MINGW-packages... I think I forgot to update that public main branch...

Yep, totally did. Downloaded https://github.com/git-for-windows/git/releases/download/v2.45.1.windows.1/MINGW-packages.bundle, pulled its git-2.45.1 branch, pushed. It should work now.

[dennisameling]

Yep, totally did. Downloaded https://github.com/git-for-windows/git/releases/download/v2.45.1.windows.1/MINGW-packages.bundle, pulled its git-2.45.1 branch, pushed. It should work now.

Thank you so much! Let's try again.

I just push the embargoed-builds branch that I used to generate v2.45.1's artifacts; I substantially revamped the way things work with existing tags, it's now more a branch-deployment model, where git-sdk-32, git-sdk-64, git, build-extra and MINGW-packages all have a, say, git-2.45.1 branch from which they build.

Just went through a few commits in that branch. There's some great things in there! Let me know if I can help testing or getting that revamped pipeline over the finish line 😊

[Alovchin91]

Thank you so much! Let's try again.

It succeeded! 🎉 Though for some reason pkg-aarch64.zip hasn’t been published 🤔 I could download it from the pkg step logs, but it would be nice if it’s still published as an artifact of the job.

[dennisameling]

Though for some reason pkg-aarch64.zip hasn’t been published 🤔

It was published here actually: https://github.com/git-for-windows/git-for-windows-automation/actions/runs/9141023895/attempts/1

Note that I had to once again cancel the installer pipeline because it was for 1+ hr. I restarted the failed jobs, which is why the artifacts are split up over two different attempts.