contrib: install the arm64 compiler tools in the Windows dependency script This lets us build arm64 wheels on Windows. We should update from VS 2017 to VS 2019, but that can wait until there's a clean Windows system available. There's a little bit of handwaving here because I originally installed some packages on the CI system by checking boxes in the GUI installer to get arm64 support, since I didn't know the name(s) of the things needed. Exporting the configuration from the GUI installer showed the list of things present, and then I was able to run `vs_buildtools.exe` on another system that previously had this dependency script run a few years ago, with just this new arg. That allowed the wheels to be built (the process failed on this second system prior to this). The only difference between the CI system configuration prior to installing arm64 stuff and this second system after, is the second system has the WinXP support component. Surprisingly, the arm64 WDK and arm64 CRT or Universal CRT doesn't seem to be required.

wheels: also build the i686 wheel in the CI People of weird hardware use i686 so testing the building it useful.

wheel: reintroduce the building of i686 wheel We now have image to make that work.

wheel: also build the musl wheel in the ci We add a trigger to not run that all the time.

wheel: add a target for amdx86_64-musl wheels These can be installed on alpine… which is quite useful.

packaging: factor the linux-wheels-x86_64 a bit This will make introduction of more variant simpler and testing quicker

packaging: propagate the make option to packaging target This is useful when using --jobs for example

packaging: remove the i686 wheel from the linux-wheels target It is currently broken.

wheels: rely on the image config to be able to access the repository The image should now have the proper config set globally to access this

packaging: explain why we purge while building wheels We also make is a bit narrower so that it is less surprising.

ci: for branches, use a single trigger This trigger will unlock all the job necessary to build wheels and upload nightly build. This should make the nightly build process more pratical. In practice right now, only run pipeline for branch by creating them explicitly on the web. So we could just run everything without trigger, but this is a decision for later. This changeset only focus on making the nightly build process somewhat manageable.

ci: add "sink" for parallel tests This work around the maximum 50 jobs dependencies.

ci: abstract the branch matching regexp This is less error prone and make debugging branch-only pipeline simpler.

branching: merge stable into default

relnotes: fix 6.9rc1 I forgot to remove a bunch of tempate stuff.

Added signature for changeset 31d45a1cbc47

Added tag 6.9rc1 for changeset 31d45a1cbc47

relnotes: add 6.9rc1

ci: let the Windows runner decide how many job they want to run With the extra concurrency at the runner level, this is no longer needed and might actually be counterproductive.

ci: adds a trigger for all pycompat jobs This will help triggering a job of all pycompat job. In addition this will also make the pycompat job block landing of Merge Request when triggered. A quite useful feature.

wheel: build windows wheel for ARM64 too

setup: preserve version part after the "+" on Windows Code introduced in early 2010 (fb203201ce30) was dropping that part after "+". The rational is to preserve version on the format w.x.y.z where each part is a number. However we have not been using that format for a while (e.g. the rc suffix) and nobody reported any fire. So I am assuming that this code serve no purpose and I am dropping it. We can reintroduce a newer version of it (that would actually achieve its purpose) in the future if needed.

setup: make sure Rust build its extension for the right python Strictly speaking, only "PYTHON_SYS_EXECUTABLE" seems to be necessary, but I don't want to take a chances, as in testing "PYTHON" also had an effect.

clone: properly exclude rev-branch-cache from post clone cache warming When adding "CACHE_REV_BRANCH" to "CACHES_ALL" in e51161b12c7e, I did not expected it to impact the clone steps. However the "CACHES_POST_CLONE" set is created rather creatively. (we should fix that, but not on stable) The benchmark caught a quite significant slowdown one hardlink and ssh-stream clones. Such slow down can be reduced to around ~5% by fully warming the cache before the clone. However keeping this expensive step away from the clone operation fully fix the slowdown and preserve the initial intend. Example slowdow for hardlink clone ### benchmark.name = hg.command.clone # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.explicit-rev = none # benchmark.variants.issue6528 = default # benchmark.variants.protocol = local-hardlink # benchmark.variants.pulled-delta-reuse-policy = default # benchmark.variants.resource-usage = default # benchmark.variants.validate = default ## data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog 6.8.2: 19.799752 6.9rc0: 29.017493 (+46.55%, +9.22) after: 19.929341 ## data-env-vars.name = mercurial-public-2018-08-01-zstd-sparse-revlog 6.8.2: 0.468020 6.9rc0: 1.701294 (+263.51%, +1.23) after: 0.471934 ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog 6.8.2: 2.397564 6.9rc0: 5.666641 (+137.41%, +3.28) after: 2.428085

wheels: update the Linux wheels make target This reuse the script extracted in the previous changeset and now build the wheels with the same image and code as the CI.

wheels: factor the core of Linux wheel building into a script This will make it easy to reuse in the release process while making sure we build the wheel the same way as in the CI.

wheel: add a job uploading nightly build There are various questions around when to actually run it, and which jobs to run on the default branch, but having a working job we can decide to run manually (by running the manual dependencies) is a good step to get the wheel story from one end to the other. See inline comment for more details.

wheel: add a platform level to the wheel directories One day, we will gather all wheel in a single directory and be able to pick the right one programmatically. This days is not today… This will help clarify things if we fetch all artifacts at the same time.

setup: use the same code to compute tag from archive Let us make sure we use a consistent version across the board.

setup: factor version computation in a function We needs it for archive too.