chore(deps): bump taiki-e/install-action from 2.87.2 to 2.87.6 - #2180
chore(deps): bump taiki-e/install-action from 2.87.2 to 2.87.6#2180dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.87.2 to 2.87.6. - [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.2...v2.87.6) --- updated-dependencies: - dependency-name: taiki-e/install-action dependency-version: 2.87.6 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
da2ce7
left a comment
There was a problem hiding this comment.
The patch itself is correct and complete, but this cannot merge as it stands: the repository allowed-actions policy still carries the old exact pin, so every workflow that uses this action now fails before any job starts.
Blockers
The allowed-actions policy does not permit taiki-e/install-action@v2.87.6.
gh api repos/torrust/torrust-tracker/actions/permissions/selected-actions returns a patterns_allowed list whose only entry for this action is the exact pin taiki-e/install-action@v2.87.2. On head a90c3bb, the two triggered workflows that use the action both ended in startup_failure (Testing for push and for pull_request, and Generate Coverage Report (PR)), while every triggered workflow that does not use it (Docs Lint, OS Compatibility, Container) started normally. The same testing.yaml, differing only in this one line, started successfully on develop at 2026-09-08T15:45:11Z, so the changed pin is the discriminator. AGENTS.md (Git Workflow) requires that PRs pass all CI status checks before merge; merging now would land a develop whose test and coverage workflows do not start.
Worth flagging for whoever triages this: these three runs produce no check runs at all, so gh pr checks 2180 and the PR checks list look clean. The failures are visible only in the workflow-run list.
The fix is a settings change, not a change to this diff. Per .github/skills/dev/maintenance/update-github-workflow-actions/SKILL.md (Allowlist Failure Diagnosis), an administrator replaces the exact entry with the scoped pattern taiki-e/install-action@v2.* and re-runs the failed workflows. The skill's Delivery Policy is explicit that the workflow pin must not be weakened to a moving major tag to work around this, and the version format in this PR is already what the policy asks for.
Suggestions
- Adopting
taiki-e/install-action@v2.*once ends a recurring cost rather than fixing a one-off..github/dependabot.yamlpolls GitHub Actions daily, so every future patch bump repeats this startup failure for as long as the policy names an exact version. The same list already usesmozilla-actions/sccache-action@*, so the wildcard style is established. The.github/dependabot.yamlheader comment already records the coupling; the policy entry is what has drifted from it.
Nits
- The head branch lives in
torrust/torrust-tracker, whileAGENTS.md(Git Workflow) states that PRs targetingdevelopmust come from a fork branch, and the workflow-actions skill's Delivery Policy says the same. Dependabot cannot satisfy that constraint. Nothing to change here; the exception is worth recording inAGENTS.mdso the rule and the practice agree.
Verification
- Diff scope.
git diff --stat develop...<head>: 3 files changed, 3 insertions, 3 deletions. Only theuses:line changes, atcoverage.yaml:51,generate_coverage_pr.yaml:46,testing.yaml:80.git diff --checkis clean. - Consistency and version format.
git grep -n 'taiki-e/install-action' <head> -- .githubshows all three workflow references at@v2.87.6, none left atv2.87.2, and no moving@v2tag. The one remainingv2.87.2-era string is the illustrative example inside the workflow-actions skill document, which is documentation and correctly untouched. A sweep of all 15 workflow files confirms these three are the only consumers of the action. - Upstream 2.87.3 (2026-09-01): manifest updates for
zizmor1.30.0,ubi0.12.0,protoc-gen-connect-openapi0.25.8,mise,kingfisher,dprint. - Upstream 2.87.4 (2026-09-02): manifest updates for
uv0.12.8,protoc3.36.1,coreutils0.11.0. - Upstream 2.87.5 (2026-09-04): thirteen manifest updates (
vacuum,uv,typos,tombi,release-plz,prek,oxfmt,mise,martin,git-cliff,cargo-zigbuild,cargo-deb,biome) plus bumps to the action's own internal CI workflows. - Upstream 2.87.6 (2026-09-05): manifest updates for
rafn0.1.6,editorconfig-checker3.11.3,dprint0.57.1,convco0.7.2, pluswasm-bindgen,uvandtombimanifest refreshes and a change disabling Debian 11 in the action's own test matrix. - Tools this repository installs are untouched. Across all 53 commits in
v2.87.2...v2.87.6and all four release bodies, a case-insensitive search forgrcov,llvm-covandnextestreturns 0 matches, sogrcov,cargo-llvm-covandcargo-nextestresolve exactly as before. No security advisory and no behaviour change in the range; the onlysecuritystrings in the range are Debian archive URLs quoted in the Debian 11 CI commit. - PR metadata. Title is a valid Conventional Commits line. Base branch is
develop. The body explains the change and links release notes, changelog and compare view. LabelsContinuous IntegrationandDependenciesmatch.github/dependabot.yaml. No linked issue, which is right here:AGENTS.mdasks for an issue reference only when the PR implements or closes one. - Signing. The head commit carries a GPG signature from GitHub's signer, key
B5690EEEBB952194. A localgit log --format='%G?'reportsEpurely because that public key is not in this checkout's keyring; commits already ondevelopreport the same status for the maintainer key58508C7950C7B7A2.AGENTS.md(Essential Rules, GPG commit signing) is satisfied. - CI, re-polled at 2026-09-08T19:54:55Z.
Testing(push),Testing(pull_request) andGenerate Coverage Report (PR):startup_failure.Docs Lint(push and pull_request): success.OS Compatibility: 8 of 11 jobs green, the three macOS jobs still running.Container/Test (Docker) (release): still running. TheDocker E2Ejob of issue #2179 does not appear at all, because the workflow that contains it never started. - Allowlist evidence. No job containing the
Install Toolsstep ever reached the running state, so there is no positive evidence that the policy permits the new reference. The direct read of the repository actions policy shows that it does not.
|
Superseded by #2191. |
Bumps taiki-e/install-action from 2.87.2 to 2.87.6.
Release notes
Sourced from taiki-e/install-action's releases.
... (truncated)
Changelog
Sourced from taiki-e/install-action's changelog.
... (truncated)
Commits
7b8d471Release 2.87.6a67fcd1Update wasm-bindgen manifestefe69d3Update uv manifestce51454Update tombi manifeste3284bdUpdaterafn@latestto 0.1.650bb7c8Updateeditorconfig-checker@latestto 3.11.32e1a951Updatedprint@latestto 0.57.12d664e3Updateconvco@latestto 0.7.25f8ff1aci: Disable debian 115bf6ce0Release 2.87.5Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)