Comparing 1f8d252c68..24bb1de9b0 - jeirmeister/Cockatrice - git.JeirsLab: Get On My Lawn

jeirmeister/Cockatrice

mirror of https://github.com/Cockatrice/Cockatrice.git synced 2026-11-09 03:23:24 -08:00

Author	SHA1	Message	Date
Lukas Brübach	24bb1de9b0	[CI] Give the Ninja leg the same vcpkg scope as the Visual Studio leg	2026-10-14 16:15:05 +02:00
Lukas Brübach	d80c77bf6f	[CI] Measure Ninja against the Visual Studio generator on Windows Ninja scales its job pool to the machine it runs on, and it lets a compiler launcher through, which MSBuild does not; those two are the reasons to expect it to beat the Visual Studio generator on a 4-core runner. That is an expectation, not a measurement, so run it as an A/B next to the Visual Studio job for a week: the extra matrix entry is allowed to fail, keeps its own " (Ninja)" suffix in the job name, is never uploaded to a release and never contributes PDBs, so it can neither block a pull request nor ship anything. Ninja needs cl.exe and the MSVC environment on PATH, which the Visual Studio generator gets for free by locating the compiler itself, hence the setup-msvc-dev step for the experimental job alone. Its build gets neither the MSBuild switches nor a job count: Ninja rejects -p: options and sizes its own pool, while the Visual Studio job keeps both. cmake takes the generator platform from the environment, so it is unset for everything that is not a Visual Studio generator, where it would otherwise follow the generator around. Delete this entry once the numbers are in: if Ninja wins, switch the Windows matrix to it and fix the PDB paths with it.	2026-10-14 16:15:05 +02:00
Lukas Brübach	285e6d6825	[CI] Profile the MSBuild run this pull request measures	2026-10-14 16:15:05 +02:00
BruebachL	0c10798ef4	[CI] Build the Windows solution on more than one MSBuild node (#7379 ) Some checks are pending CodeQL / Analyze (cpp) (push) Waiting to run Details CodeQL / Analyze (actions) (push) Waiting to run Details Build Desktop / Configure (push) Waiting to run Details Build Desktop / Debian 13 (push) Blocked by required conditions Details Build Desktop / Debian 12 (push) Blocked by required conditions Details Build Desktop / Fedora 44 (push) Blocked by required conditions Details Build Desktop / Fedora 43 (push) Blocked by required conditions Details Build Desktop / Servatrice_Debian 12 (push) Blocked by required conditions Details Build Desktop / Ubuntu 24.04 (push) Blocked by required conditions Details Build Desktop / Ubuntu 26.04 (push) Blocked by required conditions Details Build Desktop / Arch (push) Blocked by required conditions Details Build Desktop / Ubuntu 26.04 cover (push) Blocked by required conditions Details Build Desktop / Windows 10 (push) Blocked by required conditions Details Build Desktop / macOS 13 Intel (push) Blocked by required conditions Details Build Desktop / macOS 14 (push) Blocked by required conditions Details Build Desktop / macOS 15 (push) Blocked by required conditions Details Build Desktop / macOS 26 Debug (push) Blocked by required conditions Details Build Desktop / Prune caches (push) Waiting to run Details Build Docker / Servatrice (arm) (push) Waiting to run Details Build Docker / Servatrice (x86) (push) Waiting to run Details Build Docker / Publish multi-platform Servatrice image (push) Blocked by required conditions Details cmake --build only passes a job count to MSBuild when it is asked for one, and .ci/compile.sh never asked, so every Visual Studio generator build ran single-node: projects were built one after another and MTT only ever parallelized the files of whichever project happened to be building. Ask for one node per core, overridable with BUILD_PARALLEL_LEVEL, and fall back to a single node when the core count is not exposed. Alongside it set EnforceProcessCountAcrossBuilds and CL_MPCount, the knobs Microsoft's build throughput write-up pairs with MTT: without them the node count and MTT multiply into more cl.exe processes than the runner has cores for. Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>	2026-10-14 16:15:01 +02:00
BruebachL	eefe0bd672	[CI] Collect an MSBuild performance summary and binary log on request (#7378 ) The Windows job spends about 28 minutes inside one "Build project" group, with nothing in it that says where the time goes: MSBuild runs single-node because no --parallel is passed, so projects build one after another and it is not visible which projects, tasks or phases are responsible. Add a --profile flag that makes the Windows build write -flp:PerformanceSummary and -bl, repeat the summary in the job log so the numbers need no download, and report the core count, which decides how much parallelism is worth asking for. The binary log is uploaded as an artifact only on the runs that asked for it. The workflow drives it from a build_profile matrix key that is empty by default, so no build changes behaviour until someone sets it. Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>	2026-10-14 14:27:58 +02:00

Diff content is not available