Repository navigation
chore(ci): bump taiki-e/install-action from 2.87.27 to 2.87.28 - #599
Conversation
Antigravity review (Gemini via Ultra)error: Individual quota reached. Please upgrade your subscription to increase your limits. Resets in 25m1s. Automated first-pass review by Earlier review rounds (newest first)Round reviewed at 2026-10-15 08:01 UTCAntigravity review (Gemini via Ultra)Updates the third-party Blocking issuesNone found. The change is trivial and consistently applied across all existing invocations. Suggestions
NitpicksNone. Automated first-pass review by |
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.87.27 to 2.87.28. - [Release notes](https://github.com/taiki-e/install-action/releases) - [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md) - [Commits](taiki-e/install-action@v2.87.27...v2.87.28) --- updated-dependencies: - dependency-name: taiki-e/install-action dependency-version: 2.87.27 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
d10000f to
f59fb02
Compare
The automated security review of 1ed72b3 (supply-chain integrity): pgo.yml builds the triggering commit, GITHUB_SHA. On a tag push that is the tag, but on Auto Release's path the event is `workflow_run`, whose SHA is main's HEAD when the run started; a commit merged after the release (this release had one: #599 landed while the binaries were being rebuilt) would be trained, gated and shipped as the release's Linux binary. pgo-linux-asset already checks out `refs/tags/<tag>`, so its HEAD is the tag's commit. A new step compares that with GITHUB_SHA; the download, stage and replace steps run only when they are equal. Otherwise the job logs a notice and the plain binary that `build` attached (built from the tag) stays. No ref is handed to pgo.yml, so the CodeQL cache-poisoning pattern 1ed72b3 removed does not come back. Verified: actionlint and check-yaml pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj
…#609) * fix(ci): attach release binaries by upload; build the tag on a re-run v3.2.0's Auto Release (run 38705637864) built all three desktop binaries and attached none. The "Upload release asset" step, softprops/action-gh-release@v3 (v3.0.3, unchanged since 2026-08-30), found the release and then failed: Unexpected error fetching GitHub release for tag refs/heads/main: HttpError: Resource not accessible by integration - .../releases/releases#update-a-release on linux, macOS and Windows alike, and again on a re-run of the failed jobs, so it is deterministic. The action ALWAYS calls `updateRelease` (tag_name, target_commitish, name, body) on an existing release before uploading (src/github.ts at v3.0.3, `release()`); v3.1.0's identical step made the same call and it succeeded. Permissions, rulesets and the action version are unchanged since then. The one difference found is that v3.2.0's tagged commit changes .github/workflows/ (ci.yml, security.yml) and v3.1.0's did not, and GitHub restricts what a GITHUB_TOKEN without the `workflows` permission may do with refs to such commits. That cause is the likeliest, not proven; the fix does not depend on it. The fix: upload with `gh release upload "$TAG" "$asset" --clobber`. An asset upload never updates the release, needs only `contents: write`, and is what this workflow's PGO step already does; `--clobber` lets a re-run replace its own asset. The release body was never this step's to touch (the old note about softprops rewriting hand-written notes is reworded to say so). A second, latent defect, found while planning the re-build: no checkout in release.yml or pgo.yml named a ref. On workflow_call and a tag push the triggering SHA is the tag's, but a `workflow_dispatch` re-build of an existing tag (the documented manual path) checked out the branch it was started from and attached main's HEAD under the tag's name; pgo.yml likewise trained and gated main's HEAD. The build and PGO-ship jobs now check out `inputs.tag || github.ref`, and pgo.yml takes an optional `ref` input that release.yml passes the same way (empty on its own dispatch, which keeps the old behaviour there). After this merges, `release.yml` is dispatched for v3.2.0 to attach the binaries to the existing release. Verified: actionlint (pre-commit "Lint GitHub Actions workflow files") and check-yaml pass. Not verifiable before merge: a workflow_dispatch run uses the default branch's copy of the file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(ci): create a missing release before uploading; normalise the tag Review of #609. - Copilot (4281436765) and agy, the same finding: the softprops action created the release when a tag had none, and `gh release upload` does not, so a plain `git push origin vX.Y.Z` (the `on: push: tags` path, which Auto Release does not cover, since it skips a version whose tag exists) would build every target and then fail every upload. A new `ensure-release` job, which `build` needs, creates the release only when `gh release view` finds none, with `--verify-tag`, the tag as its title and an empty body; an existing release and its notes are never touched. Auto Release's path and a dispatched re-build both find the release and leave it. - agy: `inputs.ref` was unreachable in pgo.yml's `bolt` job (it runs only on workflow_dispatch, where `ref` is not an input), so that checkout's `ref:` is removed rather than kept as dead text. - agy: a dispatch given `refs/tags/vX.Y.Z` named its archive `rustynes-refs/tags/...` and uploaded to that "tag": the prefix was stripped only on the tag-push branch. Both the build and PGO-ship jobs now take `${INPUT_TAG:-$GITHUB_REF}` and strip `refs/tags/` from it, and the build job reads the input through `env` instead of interpolating `${{ inputs.tag }}` into the script. - agy nits, taken because they are one line each: the concurrency groups key on `inputs.tag || github.ref` (release.yml) and `inputs.ref || github.ref` (pgo.yml), so two dispatched tags no longer share `refs/heads/main`'s group; the PGO-ship comment no longer contrasts itself with a softprops step that is gone. Verified: actionlint and check-yaml pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(ci): one concurrency key per release tag; tell absent from failed Review of #609, second round (CodeRabbit 4281515360/374/380, agy 09:47). - One key per tag: the concurrency group used `inputs.tag || github.ref`, which is `refs/tags/vX.Y.Z` on a tag push and `vX.Y.Z` on a dispatch, so a push and a dispatch for the same release could run together and `--clobber` each other's assets (a late plain Linux upload replacing the PGO one). Every use, the group and the three checkouts, is now `inputs.tag || github.ref_name`, the bare tag either way (checkout resolves a bare tag name); pgo.yml's group likewise keys on `inputs.ref || github.ref_name`. - `ensure-release` no longer reads every `gh release view` failure as "absent": only `release not found` (gh's exact text for a missing release, checked locally against a tag that has none, exit 1) leads to a create; a rate limit, 5xx or token failure prints its own message and fails the job. - A suffixed tag (`v1.0.1-rc1`, which the `v*` trigger accepts) is created with `--prerelease`. - The upload step runs `set -euo pipefail` and refuses an unset `asset` rather than passing an empty argument. Declined, with the reason in the replies: command-level deadlines on each `gh` call (each job already has a timeout, 5 minutes for ensure-release, and gh retries nothing on its own); gating `pgo` on `ensure-release` (the PGO job never touches the release; the job that ships its binary already needs `build`, which needs the release); giving `bolt` a `ref:` again (the first round asked for its removal because it runs only on dispatch, where there is no such input). Verified: actionlint and check-yaml pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(ci): check out the release as refs/tags/; PGO waits for the release Review of #609, third round. - CodeRabbit (4281612705): an unqualified `ref: vX.Y.Z` lets actions/checkout pick a BRANCH of that name over the tag, and the build would then attach that branch's binaries to the tag's release. All three checkouts (build, the PGO job via pgo.yml's `ref` input, and the PGO-ship job) now pass `refs/tags/<tag>`. A dispatch must give the bare tag, as its input description says; a prefixed one now fails at checkout instead of building something else. - agy (09:58): `pgo` now needs `ensure-release`, so a bad tag stops the run before up to 90 minutes of PGO training rather than after. Declined: normalising a `refs/tags/` prefix inside the workflow-level concurrency expression (expressions have no string-strip; the bare-tag contract above makes the key consistent), and declaring `ref` under pgo.yml's workflow_dispatch inputs (an undeclared input evaluates to the empty string by definition, which is the intended default there). Verified: actionlint and check-yaml pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(ci): skip PGO on a dispatched re-build instead of passing it a ref CodeQL on #609 (67bd24c): five HIGH "Cache Poisoning via execution of untrusted code" alerts in pgo.yml (lines 121-178). The `ref` input this PR added let a caller choose what pgo.yml checks out, and pgo.yml then builds and runs it with the default branch's cargo cache, which is the pattern the rule reports. Only the repository owner can dispatch, so it is not exploitable here, but a release fix should not add high alerts. pgo.yml is restored byte for byte to main's (no `ref` input, its own concurrency key). pgo.yml builds the TRIGGERING commit: the tag's on a tag push and on Auto Release's call, and main's HEAD only on a dispatched re-build of release.yml. So that one path skips the PGO job (`if: github.event_name != 'workflow_dispatch'`; on workflow_call the event is the caller's, workflow_run, so Auto Release still runs PGO). `pgo-linux-asset` needs `pgo`, so it is skipped too, and a dispatched re-build ships the plain Linux binary, as any run whose PGO misses its gate already does. The build and ship checkouts in release.yml keep `refs/tags/<tag>`; CodeQL raised nothing on them. Verified: actionlint passes; `git diff origin/main -- pgo.yml` is empty. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(ci): ship a PGO binary only when it was built from the tag The automated security review of 1ed72b3 (supply-chain integrity): pgo.yml builds the triggering commit, GITHUB_SHA. On a tag push that is the tag, but on Auto Release's path the event is `workflow_run`, whose SHA is main's HEAD when the run started; a commit merged after the release (this release had one: #599 landed while the binaries were being rebuilt) would be trained, gated and shipped as the release's Linux binary. pgo-linux-asset already checks out `refs/tags/<tag>`, so its HEAD is the tag's commit. A new step compares that with GITHUB_SHA; the download, stage and replace steps run only when they are equal. Otherwise the job logs a notice and the plain binary that `build` attached (built from the tag) stays. No ref is handed to pgo.yml, so the CodeQL cache-poisoning pattern 1ed72b3 removed does not come back. Verified: actionlint and check-yaml pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * docs(ci): say what pgo.yml builds on each release path Cursor on #609 (4281914967): the comment on the `pgo` job said pgo.yml builds the tag on Auto Release's call. It does not: the call is made from a `workflow_run`, whose GITHUB_SHA is main's tip when the run started. The defect that follows from it, a later main commit promoted as the tag's Linux asset, was already closed by 25c1198 (pgo-linux-asset ships only when GITHUB_SHA equals the tag's commit); this corrects the comment that described the wrong behaviour, and names that gate. Comment only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Bumps taiki-e/install-action from 2.87.27 to 2.87.28.
Release notes
Sourced from taiki-e/install-action's releases.
Changelog
Sourced from taiki-e/install-action's changelog.
Commits
1168f68Release 2.87.28db1b909Updatetombi@latestto 1.8.14fe7379Update tombi manifest7443747Update osv-scanner manifest6ff1c9bUpdate kingfisher manifestcb40720Update kache manifest4c1bf34Updatedprint@latestto 0.62.03dfabf7Updatevacuum@latestto 0.33.0a80e680Updateuv@latestto 0.13.010f4ee9Updatetombi@latestto 1.8.0Summary by CodeRabbit