- Nov 22, 2024
-
-
Arseniy Alekseyev authored
I found the existing description pretty hard to understand. Hopefully this phrasing makes things clearer.
-
Arseniy Alekseyev authored
-
- Nov 20, 2024
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
I've folded bugfixes that only exist to fix 6.9-specific things to the best of my attention span for this task.
-
Pierre-Yves David authored
I hope this is not too scary, but as discussed last month, we need to have a better compatibility story before pushing more people toward Rust.
-
Pierre-Yves David authored
As discussed last Friday after publishing the rc wheel, we need to update the rust readme and highlight that change in the release announcement if we want people using Rust to keep being able to use pip.
-
Pierre-Yves David authored
Sight.
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
We don't test them yet, but we build them, as as many other flavors.
-
- Nov 16, 2024
-
-
Matt Harbison authored
This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`, except the default pythons to build can be inferred from `setup.py` and/or `pyproject.toml`, and all use the same configuration. All we need to do is force the building of translation files, tell it to skip pypy wheels, and tell it to build universal2 wheels instead of for the current architecture.
-
- Nov 18, 2024
-
-
Raphaël Gomès authored
Possibly we would have caught the looming bug earlier if this had been named closer to what it actual is used for.
-
Raphaël Gomès authored
This is not currently a problem since the options are the same, but would have become one at some point in the future.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
The embarrassing details of how this was discovered will be kept under silence.
-
Pierre-Yves David authored
We no longer run the test while building wheels as they are build the very same ways as in the CI (that run tests).
-
- Nov 14, 2024
-
-
Matt Harbison authored
This is duplicated from the current CI config, to be able to build releases consistently outside of CI. I don't like the duplication, but I'm not worried about things changing too often, so I'm not bothering with PowerShell or some form that would allow execution by the CI runner. We should consider putting the config in `pyproject.toml`, where things like what python versions to support can be centrally controlled for all platforms. The output directory is different from CI here, but that's fine because it is intended to run this on a system that is *not* hosting the CI setup, and `dist/` is more standard. I dropped the `win32` part of the output because that implies the 32-bit Intel architecture. Apparently, arm64 builds are supported back to Python 3.9, but support is still experimental (with py3.13)[1]. The CI system starts arm64 support with Python 3.11, because that's the first version that an arm64 Python installer was available on Windows. This doesn't second guess that decision. The required `msgfmt.exe` was installed manually[2], as it isn't currently handled by the dependency installation script. Otherwise, this was successfully used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3` installed. [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe
-
Matt Harbison authored
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.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
People of weird hardware use i686 so testing the building it useful.
-
Pierre-Yves David authored
We now have image to make that work.
-
Pierre-Yves David authored
We add a trigger to not run that all the time.
-
- Nov 14, 2024
-
-
Pierre-Yves David authored
These can be installed on alpine… which is quite useful.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
This will make introduction of more variant simpler and testing quicker
-
Pierre-Yves David authored
This is useful when using --jobs for example
-
Pierre-Yves David authored
It is currently broken.
-
Pierre-Yves David authored
The image should now have the proper config set globally to access this
-
Pierre-Yves David authored
We also make is a bit narrower so that it is less surprising.
-
- Nov 14, 2024
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
This work around the maximum 50 jobs dependencies.
-
Pierre-Yves David authored
This is less error prone and make debugging branch-only pipeline simpler.
-
Raphaël Gomès authored
I forgot to remove a bunch of tempate stuff.
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
With the extra concurrency at the runner level, this is no longer needed and might actually be counterproductive.
-
- Nov 09, 2024
-
-
Pierre-Yves David authored
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.
-
- Nov 10, 2024
-
-
Pierre-Yves David authored
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
This reuse the script extracted in the previous changeset and now build the wheels with the same image and code as the CI.
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
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.
-