[Bug 56185] New: The GitLab Windows test job runs even when not needed
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(a)winehq.org Reporter: fgouget(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- It should run them when headers or tools had changed too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 --- Comment #2 from Rémi Bernon <rbernon(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 --- Comment #3 from Rémi Bernon <rbernon(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 --- Comment #4 from François Gouget <fgouget(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56185 --- Comment #5 from François Gouget <fgouget(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla