- 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.
-
- Nov 09, 2024
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
Let us make sure we use a consistent version across the board.
-
Pierre-Yves David authored
We needs it for archive too.
-
Pierre-Yves David authored
While debuging version issue, I forcibly turned "6.9" in "6.9.0". And I forgot to clean it up before 9048a0d782e1 land This is unnecessary and wrong, so lets remove that line.
-
- Nov 09, 2024
-
-
Pierre-Yves David authored
-
- Nov 10, 2024
-
-
Pierre-Yves David authored
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
Same logic as Linux and Mac, we better test that what we build and ship works.
-
- Nov 10, 2024
-
-
Pierre-Yves David authored
This will help also build the ARM64 wheel once the dependencies are installed.
-
- Nov 09, 2024
-
-
Pierre-Yves David authored
Again, cibuildwheels makes it very handy.
-
- Nov 10, 2024
-
-
Pierre-Yves David authored
There was this old outdated conditional that can simply receive our new needs… Incredibly, this is all that seems to be needed.
-
- Nov 09, 2024
-
-
Pierre-Yves David authored
The other cibuildwheels (e.g. windows) will needs it too.
-
- Nov 10, 2024
-
-
Pierre-Yves David authored
The shell script under a `.exe` name confused Windows outside MSYS and give us the following error: […]/python.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher. This is necessary to get the wheel variant of the test run to work properly.
-
Pierre-Yves David authored
This will help having concurrency on the windows runner too.
-
- Nov 11, 2024
-
-
Pierre-Yves David authored
This test is hanging the CI, so lets ignore it for now.
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
This helps make things clearer and easier to adjust in sub jobs.
-