https://bugs.winehq.org/show_bug.cgi?id=56185
Bug ID: 56185 Summary: The GitLab Windows test job runs even when not needed Product: WineHQ Gitlab Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: gitlab-unknown Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
The GitLab Windows test jobs run even for MRs that don´t touch the tests. For instance MR!4840 does not touch the test: https://gitlab.winehq.org/wine/wine/-/merge_requests/4840/diffs
And yet test-win10-21h2-32 ran (same for the 64-bit tests job): https://gitlab.winehq.org/fgouget/wine/-/jobs/48245
And the corresponding winetest.log file is empty which corresponds to an empty winetest.args file. This makes sense since build-linux systematically generates winetest.args and it's only in the Windows job that we check whether that file is empty or not.
This could be avoided by generating dynamic child jobs in build-linux. Then the check for whether it is necessary to run the Windows tests could be done in build-linux and a 'dummy: rules: when: never' job could be generated if nothing needs to be run.
See below for an example of a dynamic child job. https://blog.devops.dev/using-dynamic-pipelines-in-gitlab-583cf4f6acd0
https://bugs.winehq.org/show_bug.cgi?id=56185
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=56185
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- It should run them when headers or tools had changed too.
https://bugs.winehq.org/show_bug.cgi?id=56185
--- Comment #2 from Rémi Bernon rbernon@codeweavers.com --- This is indeed not ideal but unless I'm mistaken with something else, I think Gitlab child pipelines are confusing, and makes it difficult to figure what job has failed (you have to click multiple times to get into the child pipeline details).
https://bugs.winehq.org/show_bug.cgi?id=56185
--- Comment #3 from Rémi Bernon rbernon@codeweavers.com --- Fwiw it's probably the only way to do it with Gitlab pipelines, and I can live with it, but maybe we could have the child pipeline be used only as a "Windows tests" job, and not replace the individual and direct build-linux / build-mac / test-linux* (and eventual? test-mac*) jobs.
https://bugs.winehq.org/show_bug.cgi?id=56185
--- Comment #4 from François Gouget fgouget@codeweavers.com --- Sure there's no reason for build-linux and build-mac to be dynamic jobs. The test-linux-32 job always runs all the tests anyway so it does not need to be dynamic either. Same for test-linux-64 since it always runs a single test: dinput. The same would likely be true for any platform that runs the tests in Wine: so many parts of Wine can impact the test that they are likely to always run tests.
So the Windows tests are really the only ones where it makes sense to use a child pipeline.
I think Gitlab child pipelines are confusing, and makes it difficult to figure what job has failed
It's actually really not that hard.
https://bugs.winehq.org/show_bug.cgi?id=56185
--- Comment #5 from François Gouget fgouget@codeweavers.com --- (In reply to Nikolay Sivov from comment #1)
It should run them when headers or tools had changed too.
Strictly speaking yes. However 99% of the time header and tool changes don't impact the tests on Windows and the more test units we run per MR on average, the fewer test configurations (32/64 bit, Windows versions, GPUs, multi-screen setups, etc) can be tested. So it's a balancing act unless we can just throw unlimited resources at the problem (hardware for the VM hosts, Windows VMs and licenses, administrator time).
-
WineHQ Bugzilla