[PATCH v2 0/1] MR8453: Draft: tools: Remove ~/.wine on every gitlab test run.
Otherwise leftover settings from previous runs interfere with current tests. -- v2: tools: Remove ~/.wine on every gitlab test run. https://gitlab.winehq.org/wine/wine/-/merge_requests/8453
From: Jinoh Kang <jinoh.kang.kr(a)gmail.com> Otherwise leftover settings from previous runs interfere with current tests. --- tools/gitlab/test.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/gitlab/test.yml b/tools/gitlab/test.yml index 58ce75e8cb0..a36fbb58fc4 100644 --- a/tools/gitlab/test.yml +++ b/tools/gitlab/test.yml @@ -43,7 +43,8 @@ - ln -sf $BASEDIR/wine-gecko-$GECKO_VER-x86.msi $BASEDIR/wine-gecko-$GECKO_VER-x86_64.msi usr/local/share/wine/gecko - ln -sf $BASEDIR/wine-mono-$MONO_VER-x86.msi usr/local/share/wine/mono - pulseaudio --start --exit-idle-time=-1 - - wine wineboot.exe -u + - rm -rf ~/.wine + - wine wineboot.exe - wineserver -w - printf '\e[0Ksection_end:%s:wine_test_prepare_env\r\e[0K' "$(date +%s)" -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/8453
On Fri Jun 27 14:51:32 2025 +0000, Rémi Bernon wrote:
Well if it's truly shared and unless it's moved first to some other location, removing it will have some bad side effects to concurrent runs. I don't think it's shared at all. Your "fails when multiple MRs were posted in a short time" observation might as well be a coincidence and other factors in play.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108234
On Fri Jun 27 14:56:01 2025 +0000, Jinoh Kang wrote:
I don't think it's shared at all. Your "fails when multiple MRs were posted in a short time" observation might as well be a coincidence and other factors in play. (Besides, if it were *really* shared, sooner or later it fail loudly and burst into flames (instead of subtle hard-to-debug failures like "changed display settings"). That's how we know your speculation is correct, and we can proceed with your MR knowing it's the correct fix.)
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108235
Well if it's truly shared and unless it's moved first to some other location, removing it will have some bad side effects to concurrent runs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108233
On Fri Jun 27 14:54:36 2025 +0000, Jinoh Kang wrote:
(Besides, if it were *really* shared, sooner or later it fail loudly and burst into flames (instead of subtle hard-to-debug failures like "changed display settings"). That's how we know your speculation is correct, and we can proceed with your MR knowing it's the correct fix.) Tests are broken when MRs are running concurrently, it is one plausible explanation and I don't have another.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108236
On Fri Jun 27 14:55:35 2025 +0000, Rémi Bernon wrote:
Tests are broken when MRs are running concurrently, it is one plausible explanation and I don't have another. I have another explanation: that's because you were posting MRs in a short time period, and the old container from previous *completed* test run was cached and reused for the next CI run. That didn't happen when there were enough delay between MRs, which gave ample time for the container cache (and thus ~/.wine) to be flushed. It had nothing to do with concurrent runs. How about that?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108237
On Fri Jun 27 15:02:23 2025 +0000, Jinoh Kang wrote:
I have another explanation: that's because you were posting MRs in a short time period, and the old container from previous *completed* test run was cached and reused for the next CI run. That didn't happen when there were enough delay between MRs, which gave ample time for the container cache (and thus ~/.wine) to be flushed. It had nothing to do with concurrent runs. How about that? (Anyway I don't think your hypo was invalid *per se*, this MR is orthogonal. I was just remarking that choosing $BASEDIR may not be the best option since it's actually persisted and reused across runner invocations.)
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108240
Fwiw I see no evidence that ~/.wine is left around across runs (and neither than it's shared... but well). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108263
On Fri Jun 27 15:04:29 2025 +0000, Jinoh Kang wrote:
(Anyway I don't think your hypo was invalid *per se*, this MR is orthogonal. I was just remarking that choosing $BASEDIR may not be the best option since it's actually persisted and reused across runner invocations.) Assuming the ~/.wine is not shared at all (and not persisted either), it's also possible that concurrent gitlab runners have inconsistent configuration. -concurrent-0 has the correct config, but then -1, -2, etc have different configuration and/or host environment.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108299
On Sat Jun 28 02:47:26 2025 +0000, Jinoh Kang wrote:
Assuming the ~/.wine is not shared at all (and not persisted either), it's also possible that concurrent gitlab runners have inconsistent configuration. -concurrent-0 has the correct config, but then -1, -2, etc have different configuration and/or host environment. It is clear gitlab leaves behind files after every job. See e.g. https://gitlab.winehq.org/wine/wine/-/jobs/169445 where it has to remove leftover directories from a previous build. Note also that the test job https://gitlab.winehq.org/wine/wine/-/jobs/169451 doesn't mention removing any files.
I think a better solution may be to put the `WINEPREFIX` in the current directory (which should be unique between runners) and clean that up at the end of the tests, or before starting the tests. Another (probably even better) solution would be to configure the runners to not allow storing changes outside of the current directory, and maybe do a `git clean -fdx` at the end of every job. Although I don't know anything about configuring the runners, so I don't know what's possible there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8453#note_108312
participants (4)
-
Jinoh Kang -
Jinoh Kang (＠iamahuman)
-
Rémi Bernon
-
Sven Baars (＠sbaars)