Repository navigation
Replies: 1 comment
|
Patch 2 is open as #31424. It was measured first on GitHub's runners as two fork pull requests on the same base (
All four jobs were green off the copied binary. One observation separate from the patch: on the first run On running a workflow's tests from one script instead of one job each (a suggestion from JalonSolov, relayed to us after this was posted): it is the strongest form of the lever in section 3, and the map gives its bound. 83 of the 132 build-V instances are repeats inside one workflow. One job per workflow (per operating system, since a matrix entry on another OS cannot share the binary) removes those 83 builds and the 83 runner starts and queue waits that go with them, and under a backed-up queue the waits are the part that hurts most. #31424 is the artifact form of the same change for one workflow; the script form avoids even the artifact round trip, which at 3 s is not where the time goes. The trade: the jobs then run in sequence on one runner, so a workflow's wall time becomes the sum of its jobs less the repeated builds, and one named red job in the checks list becomes one red whose step has to name the failing suite. Where the map says it would pay, counting instances that each build V (some of these are spread over operating systems, so each workflow's own figure is at most this): The script form has not been measured on runners from here; the figures above are the map's counts. |
Uh oh!
There was an error while loading. Please reload this page.
We surveyed vlang/v's Actions workflows from the API on 28 October (authenticated
gh), replayed the trigger filters of all 64 workflow files at5cde58423, and timed pieces of the build and the test suite on a 4-vCPU VM. This post has the four findings with how sure we are of each, two small pull requests, and the full map at the end. Nothing here proposes a rewrite of the CI; the numbers are offered for the maintainers to decide on.1. Fork pull requests run zero jobs because their approval expires
The core workflows have had no successful run since August (CI Linux last green 14 Aug, Windows gcc 28 Aug, the sanitizers 16 Aug, tools 27 Aug, other-CI 26 Aug). Of the last 100 runs of each, about 71 were still queued, 23 cancelled, 5 awaiting approval, and none succeeded.
Part of that is a state the CLI misreports.
gh run viewon a failed run from a fork says "This run likely failed because of a workflow file issue", but the run page's annotation reads:Every zero-job failure we read carries it: the 20 workflows on PR #31306's last push, the 39 on PR #31358's, and 93 of the last 100 failed pull-request runs on 29 October, all from forks. A fork pull request's workflows wait for a maintainer's approval on each push and fail with zero jobs when it lapses; PR #31161's first push ran 42 jobs, its next push one, and the two after it none. The workflow files are not at fault (actionlint 1.7.7 reports nothing for
linux_ci.yml, and the fork's.github/workflowstree was identical to master's at the merge). The lever is the repository's fork-PR approval setting under Actions, which we cannot read.Sure of: the annotation text and the counts above. Not checked: what the setting is currently set to.
2. The unit-test matrix is the largest single cost
compiler_ci.ymlruns ten shards ofv run vlib/v/test_all.vsh --units-only --shard N/10on every push to master. One shard (--shard 1/10) did not finish in 40 minutes on the 4-vCPU VM (17 files done,vlib/v/compiler_tests/files at 10 to 143 s each); the workflow allows 120. On that evidence ten shards cost at least 400 job-minutes per master push, against 333 job-minutes for the last green run of every other workflow together, and master takes about 28 pushes a day. This is our VM, not a GitHub runner, so it is a floor. A nightly run, plus a pull-request run of what a change touches, would remove most of it.3. Most jobs rebuild V
Of 198 job instances in 126 job templates, 132 run
make(ormakev.bat) and 8 use the setup-v action. A coldmaketook 167 s (median of 3) and 1.78 GB RSS on the VM; the survey's "Build V" steps run 1.5 to 5.8 minutes. 83 of the 132 are repeats inside one workflow, an upper bound on what sharing a build could remove (matrix entries on other operating systems cannot share a Linux binary).Two pull requests:
if: ${{ false }}of the disabledpackage2-linuxjob from its step to the job, so three runners are no longer started to skip one step.docs_ci.ymland handsvandthirdparty/tccto its four jobs as a one-day artifact; it is being run on a fork first so the artifact round trip has a measured time on real runners before it is offered.4. What fires per change
Replaying each workflow's push and pull_request filters (branch and path rules, including
!negations) against six example changes, with the survey's minutes split across a workflow's jobs by instance count:The classification behind the last column (every pull request / path-triggered / merge to master only / nightly / manual) is a proposal; the map below marks it per workflow, with a star where it is a judgement call.
The suite, briefly
v testruns min(CPUs, a memory budget, 4) workers; CI Linux setsVJOBS=4on a 4-CPU runner, so it is CPU-bound there. In the 760 of 6,166 test files we timed (the first directories alphabetically, so not a random sample), 74% of the time is compiling, not running: 31 minutes of compile to 11 of run. The largest single files:vlib/v/markused/custom_str_test.v(72 s compile, 156 s run),vlib/mcp/mcp_test.v(70 + 69 s), and several indb/redis,db/pgandencoding/coseat 20 to 37 s of compile for a run of under a second. A warm module cache makes anet.httpprogram build 15 times faster than cold (44 s to 2.9 s on the VM); every CI job starts cold.Not verified
v test vlibdid not complete; the sample is 760 files.The map
One row per workflow file at
5cde58423. Jobs is templates / instances after matrix expansion. Timeout in minutes. Minutes are the survey's job-minutes for the last successful run of that workflow ("unmeasured" when it had no timed run in the last month). Class is the proposal of section 4; a star marks a judgement call.64 workflows
The full page with the per-file timings, the build-once design and the patch bytes is available on request.
All reactions