Tue, 08 Oct 2024 15:54:59 +0200 relnotes: skip the test if the source repository is not readable stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51961
relnotes: skip the test if the source repository is not readable The test want to run the relnot extension, with the tested mercurial, on the original repository. This is not always possible (e.g. when running with --pure and the repository use zstd for example). So we skip the test in this case.
Tue, 08 Oct 2024 15:54:59 +0200 check-code: document reason and suggest alternative to exit code negation stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51960
check-code: document reason and suggest alternative to exit code negation The check was introduced in f48b075ff088. We trust the explanation from there.
Tue, 08 Oct 2024 15:54:59 +0200 ci: drop the HGMODULEPOLICY overwrite stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51959
ci: drop the HGMODULEPOLICY overwrite The test runner have been setting them properly for a while now. So we don't need to do it manually anymore.
Tue, 08 Oct 2024 15:54:59 +0200 test: preserve the existing module policy config for testrepohg resuse stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51958
test: preserve the existing module policy config for testrepohg resuse The test runner is, righfully, setting HGMODULEPOLICY to match the flavor requests to run the tests. However this mess with the `testrepohg` ability to run properly, as the newly set policy might be incompatible with its installation, or its ability to read the test repo. So we preserve the initial value in a dedicated variable and use it in the `testrepohg` helper.
Tue, 08 Oct 2024 15:54:59 +0200 module-policy: ignore empty module policy stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2024 15:54:59 +0200] rev 51957
module-policy: ignore empty module policy This make the variable easier to work with, the empty value is not ambiguous about not wanting to get in the way.
Fri, 04 Oct 2024 13:26:29 -0400 tests: provide an alternate fake lock for filesystems without symlink support
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 13:26:29 -0400] rev 51956
tests: provide an alternate fake lock for filesystems without symlink support
Fri, 04 Oct 2024 12:53:02 -0400 tests: disable `worker.backgroundclose` to stabilize a test on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 12:53:02 -0400] rev 51955
tests: disable `worker.backgroundclose` to stabilize a test on Windows TIL that `worker.enabled=0` doesn't prevent these workers from spinning up. At any rate, there's already a whole lot of conditionalized output following `cat client.log`, the placement of the "starting 4 threads for background file closing" message seems unstable, and we don't care about those worker threads here. Preventing the message is better for test maintenance.
Fri, 04 Oct 2024 11:22:30 -0400 tests: fix lock file path mangling in `test-racy-mutations.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 11:22:30 -0400] rev 51954
tests: fix lock file path mangling in `test-racy-mutations.t` on Windows I guess `$TESTTMP_FORWARD_SLASH` gets translated by MSYS. This was in the `.foo_commit_out` file: sh: C;C:\\MinGW\\msys\\1.0\\Users\\Matt\\AppData\\Local\\Temp\\hgtests.1qc8jmdl\\child2\\test-racy-mutations.t-skip-detection\\waitlock_editor.sh: $ENOENT
Fri, 04 Oct 2024 11:10:45 -0400 tests: stabilize `test-status-eacces.t` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 11:10:45 -0400] rev 51953
tests: stabilize `test-status-eacces.t` on Windows As noted earlier, `chmod` doesn't complain in MSYS, but also doesn't alter the file permissions such that they are unreadable. I'm guessing the other lines of output in this area that are gated on `rhg` (or not) will also need this, but I don't want to dig too deeply into something that is apparently working well enough.
Fri, 04 Oct 2024 01:40:35 -0400 run-tests: bump the default timeout on Windows to 4x the normal value
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Oct 2024 01:40:35 -0400] rev 51952
run-tests: bump the default timeout on Windows to 4x the normal value There are a ridiculous number of tests that timeout on Windows with the 360 sec default (~60). And because of the bug where timed out tests still run to completion before the results are thrown away[1], the timeout does nothing but waste time, so there's no reason to try to find a lower value that still works. For reference on my system: # Ran 909 tests, 116 skipped, 119 failed. python hash seed: 2052473208 real 151m44.322s user 0m0.077s sys 0m0.046s [1] I thought that I wrote a bug for this, but search isn't finding it.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 tip