Repository navigation
release: add Linux and macOS binary tarballs and rename their artifacts - #1001
Conversation
83e4d62 to
0d964f0
Compare
|
Open question: should the Windows |
0d964f0 to
74a4ae0
Compare
Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Official Linux and macOS releases currently offer only installers. Provide binary tarballs alongside them so consumers can extract the release payload without running a platform-specific installer. Reuse the staged installation trees to keep the archives aligned with the installers, including signed macOS binaries when ESRP is enabled. Preserve the usr/local layout and support files expected by the existing builds rather than creating a separate relocatable distribution. Linux archives retain the Debian package's runtime dependencies. Assisted-by: GPT-6.1 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Today there is no clear differentiation between the Linux and Mac release artifacts other than their file extensions (.deb for Linux Debian package, and .pkg for macOS Installer package). Since the tarballs use the same extension on both platforms (.tar.gz) we need a more clear way to tell them apart. Add a macos- and linux- prefix to the architecture part of the artifact file names for the tarballs. Note: it technically is possible to tell the difference because the Linux artifact is "microsoft-git-*" and the Mac artifact is "git-*" but this is very subtle. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Binary tarballs now include the platform before the CPU architecture, but macOS installer packages still omit it. Give packages the same macos-<architecture> suffix so installers and archives follow a consistent naming convention. Rename the package at build time rather than only when staging release assets so the DMG contains the same filename as the standalone package. Keep packaging, notarization and the Azure installer lookups aligned. Assisted-by: GPT-6.1 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
Linux tarballs already identify their platform in the filename, while Debian packages do not. Give both artifacts the same microsoft-git_<version>_linux_<architecture> basename so release assets follow a consistent naming convention. The build and staging steps must agree on this basename; otherwise staging tries to move a file that dpkg-deb never created. Keep the Debian package metadata unchanged: the qualifier identifies the release asset, not the installed package. Assisted-by: GPT-6.1 Sol Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
74a4ae0 to
d6d9570
Compare
I guess an |
Well, if we're already fuzzy matching for the version number - like |
- name: Download microsoft/git installers
if: steps.check.outputs.result == ''
shell: cmd
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release download %GIT_VERSION% --repo microsoft/git --pattern "Git*.exe" --dir MicrosoftGitYep. VFS for Git's CI/PR workflows match artifacts like # Windows (ARM64)
-Git-2.55.0.vfs.0.10-arm64.exe
+Git-2.55.0.vfs.0.10-windows-arm64.exe
-PortableGit-2.55.0.vfs.0.10-arm64.7z.exe
+PortableGit-2.55.0.vfs.0.10-windows-arm64.7z.exe
# Windows (x64)
-Git-2.55.0.vfs.0.10-64-bit.exe
+Git-2.55.0.vfs.0.10-windows-x64.exe
-PortableGit-2.55.0.vfs.0.10-64-bit.7z.exe
+PortableGit-2.55.0.vfs.0.10-windows-x64.7z.exeIt would impact the next WinGet manifest version however, which may need manual edits for the initial transition: Installers:
- Architecture: x64
Scope: user
InstallerUrl: https://github.com/microsoft/git/releases/download/v2.55.0.vfs.0.10/Git-2.55.0.vfs.0.10-64-bit.exe
InstallerSha256: AE39FC42ED4E4834E719B7F730BD42B94A57696ABD2EECE5736AB630C3847F91
- Architecture: x64
Scope: machine
InstallerUrl: https://github.com/microsoft/git/releases/download/v2.55.0.vfs.0.10/Git-2.55.0.vfs.0.10-64-bit.exe
InstallerSha256: AE39FC42ED4E4834E719B7F730BD42B94A57696ABD2EECE5736AB630C3847F91
- Architecture: arm64
Scope: user
InstallerUrl: https://github.com/microsoft/git/releases/download/v2.55.0.vfs.0.10/Git-2.55.0.vfs.0.10-arm64.exe
InstallerSha256: B5DDD4D69F3F1D39E82F0784C2EC19F0066AE639876C5223AA1153C4DA82B6A2
- Architecture: arm64
Scope: machine
InstallerUrl: https://github.com/microsoft/git/releases/download/v2.55.0.vfs.0.10/Git-2.55.0.vfs.0.10-arm64.exe
InstallerSha256: B5DDD4D69F3F1D39E82F0784C2EC19F0066AE639876C5223AA1153C4DA82B6A2Thoughts on replacing |
Sure, let's go for it! If we're already changing the file name, might just as well address this historical wart, too. |
|
Do you prefer |
Yeah, I think on Windows we'd want to stick to x64 and arm64. |
Matthew John Cheetham (mjcheetham)
changed the title
|
Actually, I'm going to leave the Windows rename altogether. Sadly there's product code in Git for Windows that we inherit in Microsoft Git that hardcodes "64-bit".. namely the updater: if test -d /clangarm64/bin
then
arch_bit=arm64
prefix=/clangarm64
else
arch_bit=${bit}-bit
prefix=/mingw$bit
fi download=$(echo "$releases" |
grep '"browser_download_url": "' |
grep "$arch_bit\.exe" |
sed -E 's/.*": "([^"]*).*/\1/')Any such rename would need more careful coordination with Git for Windows upstream. |
Matthew John Cheetham (mjcheetham)
changed the title
2cb0657
into
vfs-2.56.0
How about folding that into Git for Windows v3.0? That version bump will be bumpy anyways... |
2 participants
Official Linux and macOS releases currently offer only installers. Provide binary tarballs alongside them so consumers can extract the release payload without running a platform-specific installer.
Reuse the staged installation trees to keep the archives aligned with the installers, including signed macOS binaries when ESRP is enabled. Preserve the usr/local layout and support files expected by the existing builds rather than creating a separate relocatable distribution. Linux archives retain the Debian package's runtime dependencies.
In addition, let's add a
macos-andlinux-infix to the architecture part of the artifact file names for the packages and tarballs. Why? Today there is no clear differentiation between the Linux and Mac release artifacts other than their file extensions (.deb for Linux Debian package, and .pkg for macOS Installer package).Note
It technically is possible to tell the difference because the Linux artifact is "microsoft-git-" and the Mac artifact is "git-" but this is very subtle.
Note
We continue to keep the Windows artifacts named the same. The old 'wart' of the x64 Windows artifacts being named "64-bit" (since this was before ARM64 builds were a thing) cannot be easily fixed here since the inherited production code from Git for Windows (namely the updater) relies on the exact naming of "64-bit" 😢
The resulting published artifacts following this changes are now: