- Nov 08, 2024
-
-
Pierre-Yves David authored
This should help to identify the module that are the slower to analyze.
-
- Nov 06, 2024
-
-
Pierre-Yves David authored
We test wheel building for all supported version and use them where applicable The usage is more verbose than I wish because .gitlab-ci is not that great.
-
Pierre-Yves David authored
This produce wheel that are more universal and identical to the one we want to publish.
-
Pierre-Yves David authored
There is no need for large machine for this job, Python will be mostly singled threaded anyway.
-
Pierre-Yves David authored
we add the `MERCURIAL_SETUP_FORCE_TRANSLATIONS` variable that is intended to make sure we don't stop building the translation silently.
-
Pierre-Yves David authored
We adjust a couple of job to consistently use double space identation. This will make the next changesets clearer.
-
- Nov 04, 2024
-
-
Matt Harbison authored
This fixes: --- C:/Users/Matt/hg/tests/test-check-module-imports.t +++ C:/Users/Matt/hg/tests/test-check-module-imports.t.err @@ -43,3 +43,15 @@ > -X tests/test-verify-repo-operations.py \ > -X tests/test-extension.t \ > | sed 's-\\-/-g' | "$PYTHON" "$import_checker" - + hgext/zeroconf/Zeroconf.py:86: stdlib import "socket" follows local import: select\r (esc) + hgext/zeroconf/Zeroconf.py:87: stdlib import "struct" follows local import: select\r (esc) + hgext/zeroconf/Zeroconf.py:88: stdlib import "threading" follows local import: select\r (esc) + hgext/zeroconf/Zeroconf.py:89: stdlib import "time" follows local import: select\r (esc) + hgext/zeroconf/Zeroconf.py:90: stdlib import "traceback" follows local import: select\r (esc) + mercurial/posix.py:18: stdlib import "stat" follows local import: select\r (esc) + mercurial/posix.py:19: stdlib import "sys" follows local import: select\r (esc) + mercurial/posix.py:20: stdlib import "tempfile" follows local import: select\r (esc) + mercurial/posix.py:21: stdlib import "typing" follows local import: select\r (esc) + tests/tinyproxy.py:19: stdlib import "socket" follows local import: select\r (esc) + tests/tinyproxy.py:20: stdlib import "sys" follows local import: select\r (esc) + [1] ERROR: test-check-module-imports.t output changed
-
- Oct 25, 2024
-
-
Matt Harbison authored
This is currently only manually invoked, and allows for failure because we only have a single runner that takes over 2h for a full run, and there are a handful of flakey tests, plus 3 known failing tests. The system being used here is running MSYS, Python, Visual Studio, etc, as installed by `install-windows-dependencies.ps1`. This script installs everything to a specific directory instead of using the defaults, so we adjust the MinGW shell path to compensate. Additionally, the script doesn't install the launcher `py.exe`. It is possible to adjust the script to install it, but it's an option to an existing python install (instead of a standalone installer), and I've had the whole python install fail and rollback when requested to install the launcher if it detects a newer one is already installed. In short, it is a point of failure for a feature we don't (yet?) need. Unlike other systems where the intepreter name includes the version, everything here is `python.exe`, so they can't all exist on `PATH` and let the script choose the desired one. (The `py.exe` launcher would accomplish, using the registry instead of `PATH`, but that wouldn't allow for venv installs.) Because of this, switch to the absolute path of the python interpreter to be used (in this case a venv created from the py39 install, which is old, but what both pyoxidizer and TortoiseHg currently use). The `RUNTEST_ARGS` hardcodes `-j8` because this system has 4 cores, and therefore runs 4 parallel tests by default. However on Windows, using more parallel tests than cores results in better performance for whatever reason. I don't have an optimal value yet (ideally the runner itself can make the adjustment on Windows), but this results in saving ~15m on a full run that otherwise takes ~2.5h. I'm also not concerned about how it would affect other Windows machines, because we don't have any at this point, and I have no idea when we can get more. As far as system setup goes, the CI is run by a dedicated user that lacks admin rights. The install script was run by an admin user, and then the standard user was configured to use it. If I set this up again, I'd probably give the dedicated user admin rights to run the install script, and reset to standard user rights when done. The python intepreter failed in weird ways when run by the standard user until it was manually reinstalled by the standard user: Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding Additionally, changing the environment through the Windows UI prompts to escalate to an admin user, and then setting the user level environment variables like `TEMP` and `PATH` (to try to avoid exceeding the 260 character path limit) didn't actually change the user's environment. (Likely it changed the admin user's environment, but I didn't confirm that.) I ended up having to use the registry editor for the standard user to make those changes.
-
- Oct 27, 2024
-
-
Pierre-Yves David authored
First step into building and testing wheel automatically.
-
Pierre-Yves David authored
We start to have a lot of job, grouping them help to clarifying the pipeline. We don't actually create dependency between each stage, so everything still run concurrently. However we are about to introduce some wheel-building job that will be reused by some tests. So some dependencies are coming.
-
Pierre-Yves David authored
All the other job use this syntax, so lets us it there too.
-
- Oct 26, 2024
-
-
Matt Harbison authored
-
Matt Harbison authored
-
- Oct 22, 2024
-
-
Pierre-Yves David authored
If our current source files were not compatible with Python 3, we would know by now. This check has not been relevant for a couple of years now and we can safely remove it.
-
- Oct 21, 2024
-
-
Matt Harbison authored
One of the modern pythons was crying about the old version importing `distutils`.
-
- Oct 19, 2024
-
-
Matt Harbison authored
Note that python 3.11 adds an installer for arm64, which we ignore here because I don't have a Windows system running arm64, and it's likely we will be dropping support for some platforms before I get my hands on one.
-
Matt Harbison authored
Python3.8 was already at its last version with an installer, FWIW.
-
Matt Harbison authored
I'm tempted to drop 3.8 too, since we use 3.9 on Windows.
-
Matt Harbison authored
The new minimum this cycle is py3.8.
-
- Oct 14, 2024
-
-
Matt Harbison authored
Right now, we only have a single machine with a single runner, so don't create a bottleneck by default.
-
- Oct 08, 2024
-
-
Matt Harbison authored
This is running from a venv, created with the packages from the requirements file in the `test-setup-future-work` topic being discussed separately. We can basically reuse the existing `test_c` configuration as-is, but there was one small issue- if the clone from the previous CI run is still present in `/tmp`, the clone for the current run fails. It's not a problem for the current setup because a new container is instantiated, so the easy fix is to simply delete the clone first. (The Windows CI avoids this by not cloning in the first place.) It looks like it takes ~80m to run the whole test suite on the current system.
-
- Oct 13, 2024
-
-
Pierre Augier authored
-
Pierre-Yves David authored
The goal here is to avoid showing tool version in all case as this create issue for non linux/docker runner that might not have some of them installed. This is currently relevant for the coming mac runner that does not have clang-format installed and does not needs its. This might also be useful in the future to use narrower docker image more specialized for each jobs.
-
- Oct 10, 2024
-
-
Pierre-Yves David authored
Python3.13 is du to be released soon. We better make sure we work with it.
-
- Oct 08, 2024
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
The check was introduced in f48b075ff088. We trust the explanation from there.
-
Pierre-Yves David authored
The test runner have been setting them properly for a while now. So we don't need to do it manually anymore.
-
- Sep 19, 2024
-
-
Matt Harbison authored
-
Matt Harbison authored
-
- Sep 10, 2024
-
-
Pierre-Yves David authored
The rust-cpython binding got 3.12 support very recently, it is worse keeping on a tighter watch.
-
- Aug 28, 2024
-
-
Pierre-Yves David authored
It seems like a good idea to be able to test the lowest version we support. And there have been enougth issue with 3.12 that we need to be able to make sur we do not break it. We should probably get a matrix setup for more version and flavor, but that is a simple and efficient start.
-
- Sep 10, 2024
-
-
Pierre-Yves David authored
As discussed on the mailing list¹, these are old version that seems safe to drop. Python 3.8 comes with various improvement especially regarding typing capabilities. [1] https://lists.mercurial-scm.org/pipermail/mercurial-devel/2024-July/297998.html
-
Pierre-Yves David authored
The CI image has a squarer setup now.
-
- Aug 20, 2024
-
-
Matt Harbison authored
This will help with CI. I don't see a way to print the version of python that's running it. When I tried `head -n 1 $(which pytype)`, the CI run printed: #!/usr/bin/env bash Locally, that gives the path to the python interpreter in the venv, so IDK what's different.
-
- Aug 04, 2024
-
-
Pierre-Yves David authored
pytype no longer complains about the file contents.
-
Pierre-Yves David authored
It use a more recent pytype as far as I understand.
-
- Jul 25, 2024
-
-
Matt Harbison authored
Not sure when the original issue(s) were fixed, but it works for me now.
-
- Jul 23, 2024
-
-
Raphaël Gomès authored
This is finally catching up to ~3 years of tech debt.
-
Raphaël Gomès authored
This makes debugging a lot easier if anything is to go wrong, and shows output earlier.
-
Raphaël Gomès authored
This allows us to work in more environments, like when using pyenv. This syntax is compatible with all POSIX shells.
-