Repository navigation
ci(release): pass repo-token to setup-protoc in the release workflow - #29
Merged
Merged
Conversation
arduino/setup-protoc@v3 asks the GitHub API which protoc version to
install. The two steps in release.yml passed no repo-token, so the
requests were not logged in, and the macOS runners share their outgoing
address with other jobs. In the run for v0.5.0 the macOS arm64 build
stopped at "Install protoc" twice (API rate limit exceeded) and passed
at the third try.
Both steps now pass repo-token: ${{ secrets.GITHUB_TOKEN }}, as the
three steps in tui-ci.yml already did.
The item leaves the list of open decisions. It is done in PR 29.
This was referenced Oct 20, 2026
zy1233
added a commit
that referenced
this pull request
Oct 20, 2026
- Plan (status, section 10 index, revision log), execution log (new section 10.21), CHANGELOG, baselines and baseline history: the numbers of the first nextest run on the whole tree (TUI CI run 39359879537: 8,490 passed, 0 failed, 22 skipped), the test time (about 130 s with nextest, about 65 s with cargo test, same code), and the dry run of release.yml for PR #29. - Correct the r17 notes: the 7 / 4 / 3 compiles of pi-tools-api in the cargo test job were not caused by the protoc path (PR #30 shows it), and the runner never ran doctests, so nextest loses nothing there. - Remove a duplicated "verification" heading from the r17 text.
zy1233
added a commit
that referenced
this pull request
Oct 20, 2026
* ci(tui): run the TUI tests with cargo nextest
The vendored tests were written for cargo nextest (one process per test), and some say in a
comment that they are reliable only under it. TUI CI ran cargo test, where all tests of a
binary share one process.
- scripts/tui_baseline.toml: `[test] runner = "nextest"`; `--runner {cargo,nextest}` on the
command line takes the other one. The libtest path stays as it was.
- scripts/tui_baseline.py: `parse_nextest_output` reads the Summary line (nextest counts the
ignored tests and the tests removed by --skip together as "skipped") and the recap of the
failed tests (the live part has the captured output of a test, so it is not read);
`suite_command` builds the command line; the report names the runner; a missing
cargo-nextest stops the run at once, with a hint.
- stream(): after the timeout, SIGTERM to the process group, and SIGKILL 20 s later. nextest
puts each test in a process group of its own, so a SIGKILL to nextest left a hanging test
alive (measured on a demo crate); a nextest that gets a SIGTERM stops its tests.
- tui-ci.yml: install cargo-nextest 0.9.148 (taiki-e/install-action) in the test job; the job
is now called "cargo nextest (Linux x86_64)".
- 21 new unit tests. The fixtures are real output of nextest 0.9.148.
* docs(tui): say in AGENTS.md and the tui_envspy README that TUI CI runs nextest
* docs: record the nextest change and the r18 round
- Plan (status, section 10 index, revision log), execution log (new section
10.21), CHANGELOG, baselines and baseline history: the numbers of the first
nextest run on the whole tree (TUI CI run 39359879537: 8,490 passed, 0 failed,
22 skipped), the test time (about 130 s with nextest, about 65 s with
cargo test, same code), and the dry run of release.yml for PR #29.
- Correct the r17 notes: the 7 / 4 / 3 compiles of pi-tools-api in the cargo
test job were not caused by the protoc path (PR #30 shows it), and the runner
never ran doctests, so nextest loses nothing there.
- Remove a duplicated "verification" heading from the r17 text.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Plan item: pass
repo-tokento the twoarduino/setup-protoc@v3steps inrelease.yml, before the next tag. The owner chose this on 2026-10-20 (release_token).arduino/setup-protocasks the GitHub API which protoc version to install. Withoutrepo-tokenthe request is not logged in, and it uses the rate limit of the runner's address. The macOS runners share their address with many other jobs. In the run forv0.5.0, the macOS arm64 build stopped at "Install protoc" twice (API rate limit exceeded) and passed at the third try.jobs: build-tui, build-tui-macos-arm - name: Install protoc uses: arduino/setup-protoc@v3 with: version: "28.x" + repo-token: ${{ secrets.GITHUB_TOKEN }}tui-ci.ymlalready passes the token in its three steps.release.ymlwas the only file that did not.repo-tokenis an input ofarduino/setup-protoc@v3(action.yml: "GitHub repo token to use to avoid rate limiter"). The workflow already haspermissions: contents: write, so no new permission and no new secret.Base:
test/tui-env-race-audit(#28), because theCHANGELOG.mdsection this PR adds to comes from #28. Not merged. #27 and #28 are not merged either.Evidence
Releaserun 38358144687, attempt 1: the macOS arm64 build failed at "Install protoc" after 18 s (API rate limit exceeded). Attempt 2 failed at the same step after 22 s. Attempt 3 passed.release.ymlwith PyYAML shows the token in both steps:release.ymlruns on a tag push, and a manual run is a dry run (it tests and builds everything and publishes nothing). The checks of this PR do not run it, so I started a dry run on this branch: run 39360804691 passed on81171da.Install protoctook 5 s on Linux x86_64 and 6 s on macOS arm64, the two build jobs took 20 min 14 s and 30 min 15 s, andPublish to PyPIandGitHub Releasewere skipped, as designed. This shows that the file is valid and thatsetup-protocaccepts the input. It does not show that the rate limit problem is gone: that limit is random, because the runners share their address. The real test is the next tag.Merge Danger
Door: two-way. Two added lines; revert them at any time.
Blast Radius: release job only.
CIandTUI CIdo not use this file. If the token does not help, the step fails at the same place as before.