pacman-helper: stop deploying to the Azure Blobs-backed Pacman repository#709
Merged
Merged
Conversation
The Pacman repository at https://wingit.blob.core.windows.net is tied to my personal Azure account, and I have long wanted to decouple Git for Windows from that. The replacement, git-for-windows/pacman-repo, has been growing into a fully featured backend for a while: ebff2ea (pacman-helper quick_add: mirror deployments to GitHub Releases) began mirroring every deployment there, 56b46e6 (pacman-helper quick_add: use new-style database filenames locally) introduced the new naming scheme, 3fca5c7 (pacman-helper quick_add: start transitioning deployments to GitHub) and 94dde8c (pacman-helper quick_add: verify that the old/new Pacman repos are in sync) hooked the new backend into the script alongside Azure, and fd28d50 (pacman-helper: maintain per-package .versions.json index files) was the final missing piece: present and past package versions' locations can now be determined from the per-package `.versions.json` files and the git history of pacman-repo, matching the one thing for which the Azure container listing was still preferable. Both backends have been running in parallel long enough that I am confident the new one is reliable. Retiring the Azure side is also a prerequisite for starting to build UCRT64 packages, which I would rather not deploy to the legacy backend at all. Drop every code path that touched Azure Blobs: the `base_url`, `map_arch` and `arch_url` helpers, the `azure_blobs_token` plumbing, the inner loop that downloaded the old-naming-scheme `.db`/`.files` files from Azure, the cross-backend "are the databases in sync?" verification, the upload-to-Azure block at the end of `quick_action`, and the `lock`/`unlock`/`break_lock` subcommands that drove Azure Blob leases via `wingit-snapshot-helper.sh`. That helper script is now unused and will be removed in a follow-up commit. The `sanitize_db` helper used to run on each freshly-downloaded Azure copy of the database, but the duplicate-package-versions failure mode it defends against is intrinsic to the Pacman database format, not to the Azure backend (we have been bitten by it before). Keep the function and run it on the freshly-pulled pacman-repo database instead. The Azure lease was previously the only locking mechanism. The new backend has no equivalent, so the best we can do is what we already do: detect a non-fast-forward push and re-apply the database updates on top of the concurrent change. That loop, introduced in 80a77f4 (pacman-helper quick_add: allow for concurrent deployments), is left in place as the sole concurrency safeguard. Discussed in git-for-windows/git#6018 (reply in thread) and #706 (comment). Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This script was the only interface between pacman-helper.sh and the Azure Blobs-backed Pacman repository at wingit.blob.core.windows.net: it implemented the REST request signing for upload, remove, list, lock, unlock and break-lock against an Azure storage container. With the preceding commit removing every call site in pacman-helper.sh, nothing in this repository references it any longer (verified via `git grep wingit-snapshot-helper`). There is no replacement and none is needed: the new git-for-windows/pacman-repo backend speaks plain git over HTTPS, so the bespoke HMAC-SHA256 signing logic, the lease bookkeeping, and the content-type-by-extension table all become dead code together. Delete the file rather than leave it sitting as a maintenance hazard whose only remaining purpose would be to confuse a future reader looking for "how does this script reach the Pacman repository?". Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mjcheetham
approved these changes
Jun 9, 2026
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Pacman packages that Git for Windows distributes have, for many years, been served from a storage location tied to my personal Azure account. That was always uncomfortable: if ever I decided that I want to do become a goat farmer, the project would be in a bind.
So I set out to find a better home for the Pacman repository, one that the Git for Windows project could properly own. The natural answer was the Git for Windows organization on GitHub itself. The new home is
git-for-windows/pacman-repo, and for quite a while every package release has been published to both the old and the new location in parallel, so that the new one could prove itself. The default in Git for Windows' SDK has been the new location for a bit, too.It has, and it is time to retire the old one.
This PR is the switch-over: from now on, package deployments go only to the GitHub-hosted Pacman repository. The first commit is the change to the release tooling; the second removes the small helper that knew how to talk to Azure storage and now has no remaining callers.
Note: While the Azure backend allowed us to sort of lock deployments via acquired leases to avoid having two concurrent deployments fall over each other's paws, the GitHub-hosted backend cannot offer that, so we rely on replaying the entire "add packages to the Pacman database, then commit and push" dance on conflict instead, i.e. using the fact that
git pushis all or nothing as an "optimistic lock". That fallback has been in place for a long time, so one might claim that it has held up well in practice, but in reality it has never been exercised because of the lease-acquiring "lock" on Azure Blobs.Retiring the Azure side is also a somewhat of a prerequisite for picking up the upcoming UCRT64 packaging work: I'd really like to avoid dragging the legacy backend along for the ride.