Comparing 24bb1de9b0..1f8d252c68 - 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	1f8d252c68	[CI] Give the Ninja leg the same vcpkg scope as the Visual Studio leg	2026-10-14 08:14:20 +02:00
Lukas Brübach	28a5bd44e7	[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 08:14:20 +02:00
Lukas Brübach	255c713ce4	[CI] Profile the MSBuild run this pull request measures	2026-10-14 08:14:19 +02:00
Lukas Brübach	af05b85f29	[CI] Build the Windows solution on more than one MSBuild node 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.	2026-10-14 08:14:19 +02:00
Lukas Brübach	8ed6354595	[CI] Collect an MSBuild performance summary and binary log on request 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.	2026-10-14 08:14:19 +02:00

Diff content is not available