chore(deps): bump actions/github-script from 7 to 9 - #25
Conversation
Bumps [actions/github-script](https://github.com/actions/github-script) from 7 to 9. - [Release notes](https://github.com/actions/github-script/releases) - [Commits](actions/github-script@v7...v9) --- updated-dependencies: - dependency-name: actions/github-script dependency-version: '9' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
added
dependencies
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Approving. Target verified against the upstream release list, and the two red
checks are pre-existing.
The failing checks are not this PR
Lint & Format and Quick Checks fail on all five open Dependabot PRs
identically, and on master. Reproduced locally against master:
$ ruff check eosim/
Found 324 errors.
$ ruff format --check eosim/
178 files would be reformatted, 15 files already formatted
So the lint gate has been red for some time and every PR inherits it. That is
worth someone's attention on its own — a permanently red required-adjacent check
trains people to ignore it, which is how a real failure gets waved through — but
it is not a reason to hold a version bump.
Verified
All five targets in this batch exist and are current:
docker/setup-qemu-action v4 latest v4.2.0
actions/checkout v7 latest v7.0.1
ossf/scorecard-action v2.4.4 latest v2.4.4
actions/download-artifact v8 latest v8.0.1
actions/github-script v9 latest v9.0.0
I check these rather than assume Dependabot picked a real tag — worth doing,
since a bump to a tag that does not exist fails at runtime with a confusing
error rather than at review.
EoSim is also one of the repositories whose ci.yml is correctly configured
(branches: [master, main, develop]), so unlike six of its siblings its CI
actually runs on pull requests. That is why these PRs have real check results at
all.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — EoSim#25 "chore(deps): bump actions/github-script from 7 to 9"
head: 6d13c8a author: app/dependabot ci: fail (Lint & Format, Quick Checks — pre-existing on master, not caused by this PR)
Verdict: Safe to land. v9 has three documented breaking changes and I checked the inline script against all three — none apply, because the script uses only github.rest.* and context, with no require() and no getOctokit binding. Worth knowing that this PR structurally cannot exercise its own change: auto-assign.yml skips bot authors, and the author is dependabot, which is why assign shows skipping. Same CI-integrity caveats as EoSim#21.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | High | .github/workflows/ci.yml:263-278, repo branch protection, .github/workflows/ci.yml:226 | The three pre-existing CI-integrity defects detailed with evidence in the EoSim#21 review apply identically: ci-summary cannot fail (it reported pass in 3s on this PR while lint failed and six jobs were skipped), master has required_status_checks: null, and pip-audit --strict 2>/dev/null || true makes Security Scan report success unconditionally. Not introduced by this diff. |
See the EoSim#21 review for the ordered fix. |
| 2 | Low | .github/workflows/auto-assign.yml:20-22 | The changed action cannot run on this PR. The assign job is gated github.event.pull_request.user.type != 'Bot', and this PR's author is app/dependabot — hence assign: skipping in the check list. It is also gated on pull_request: types: [opened] from a non-fork, so the only way to exercise github-script@v9 here is a human opening a branch PR after this merges. A dependabot PR that changes an action dependabot's own PRs are excluded from is a genuine blind spot, not a nitpick. |
Land it, then watch the first human-authored PR after merge. If you want signal sooner, temporarily add workflow_dispatch with a hardcoded issue number, or open a trivial throwaway PR by hand. |
| 3 | Medium | CI state — Lint & Format, Quick Checks | Both red on pre-existing ruff violations in eosim/ (I001, F401, UP031, N806 across eosim/analysis, eosim/api, eosim/artifacts, eosim/cli, eosim/plugins, eosim/tests), unrelated to this diff. Every job declaring needs: lint was skipped. Note that fixing lint still would not exercise this PR — see finding 2. |
Land a ruff check --fix / ruff format pass on master separately. |
Not a finding, verified against each v9 breaking change. The script at auto-assign.yml:27-33 is a single await github.rest.issues.addAssignees({...}) using context.repo.owner, context.repo.repo and context.payload.pull_request. Checked one by one:
- "
require('@actions/github')no longer works in scripts" — the script contains norequireat all. Inapplicable. - "
getOctokitis now an injected function parameter; scripts declaringconst/let getOctokitget aSyntaxError" — the script declares no variables whatsoever. Inapplicable. - "scripts accessing other
@actions/githubinternals may need updating" —github.rest.*andcontextare the standard injected surface, not internals. Inapplicable.
v8's change is the Node 24 runtime (Actions Runner ≥ 2.327.1, satisfied by ubuntu-latest). The action is invoked with only script: — no github-token, result-encoding, retries or other input that could have been renamed. The job's permissions: block (issues: write, pull-requests: write, :6-8) is untouched; this bump widens nothing.
Recorded as correct, since it is adjacent and easy to misread. The if: condition at :20-22 is the right shape and its comment explains why: fork PRs get a read-only token so addAssignees returns 403, and bot accounts are not assignable and return 403. Skipping where assignment can never succeed is better than failing, and that is what produces assign: skipping here rather than a red check.
Architecture conformance
Conforms. Infrastructure-tier change (master design §21) to a Tier-1 Foundation repository. No source, #include, link line or manifest entry — §5.1 dependency direction untouched. Finding 1 bears on §17 and §28 in the same way as the other four EoSim PRs and is already filed as the §28.2 proposal of 2026-09-02 and the §28.3 proposal of 2026-09-03. No new proposal warranted.
Proposed changes
None to the diff. Of the five open EoSim dependabot PRs, this one, #22 (checkout 4→7) and #23 (scorecard 2.4.3→2.4.4) are safe by inspection; #24 (download-artifact 4→8) should wait for its upload-artifact pair. Repository order of operations is in the EoSim#21 review.
Verification I ran
git show origin/master:.github/workflows/auto-assign.ymlin full → the trigger, theif:gate, thepermissions:block, and the complete inline script. This is what makes each of the three v9 breaking changes checkable rather than assumed.- Read the v8.0.0 and v9.0.0 release notes from the PR body for the breaking-change list quoted above.
gh run view --job 99405042530 --log-failed(Lint & Format) and--job 99405042518(Quick Checks) → the ruff violations in finding 3.gh api repos/embeddedos-org/EoSim/branches/master/protection→required_status_checks: null;gh pr view 25 ...→UNSTABLE APPROVED MERGEABLE.
Not checked
- Nothing was executed.
github-script@v9has not run in this repository. Finding 2 is why: the one job that uses it is structurally excluded from this PR. The inapplicability of the three breaking changes is established by reading the script, which is sound for those three specific changes and is not a substitute for a run. - I did not check whether EoSim uses self-hosted runners; the Node 24 floor is satisfied by GitHub-hosted runners and unverified for anything else.
- The local EoSim checkout is dirty (179 modified tracked
.pycfiles) and two commits behindorigin/master; the sync step correctly left it alone and everything above was read fromorigin/masterviagit show. I did not stash, reset or check out anything.
Automated architecture review of 6d13c8a19a74 — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.
1 participant
Bumps actions/github-script from 7 to 9.
Release notes
Sourced from actions/github-script's releases.
... (truncated)
Commits
3a2844bMerge pull request #700 from actions/salmanmkc/expose-getoctokit + prepare re...ca10bbdfix: use@octokit/core/types import for v7 compatibility86e48e2merge: incorporate main branch changesc108472chore: rebuild dist for v9 upgrade and getOctokit factoryafff112Merge pull request #712 from actions/salmanmkc/deployment-false + fix user-ag...ff8117eci: fix user-agent test to handle orchestration ID81c6b78ci: use deployment: false to suppress deployment noise from integration tests3953cafdocs: update README examples from@v8to@v9, add getOctokit docs and v9 brea...c17d55bci: add getOctokit integration test joba047196test: add getOctokit integration tests via callAsyncFunctionDependabot 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)