chore(deps): bump actions/setup-python from 5 to 7 - #37
Conversation
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5 to 7. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@v5...v7) --- updated-dependencies: - dependency-name: actions/setup-python dependency-version: '7' 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. I verified the target exists and is current rather than assuming
Dependabot picked a real tag:
actions/setup-python target v7 latest confirmed on the upstream release list
The diff is a pure version-string change.
But be aware there is no CI behind this
The only check on this PR is a skipped assign job. That is not a quirk of this
PR — this repository's CI has not run since 2026-05-31.
# .github/workflows/ci.yml
on:
push:
branches: [main, develop]
pull_request:
branches: [main]default branch: master
main: 404 Branch not found
main was renamed or deleted around late May and the workflow was left pointing
at it. Every push to master and every pull request against it falls outside the
trigger. Filed as #38.
That matters here specifically. A major version bump of a GitHub Action is
exactly the change CI exists to validate — new runtimes, removed inputs, changed
defaults — and there is none. Approval rests on the version existing and the diff
being mechanical, not on evidence the workflow still works.
I would rather these merged after #38 than before, so the first thing the
restored CI reports is whether these bumps are good. But they are not
individually risky and I am not going to hold them for it.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eAI#37 "chore(deps): bump actions/setup-python from 5 to 7"
head: 950052f author: app/dependabot ci: none (no checks ran on this PR)
Verdict: Safe to merge on the evidence. I checked both intervening majors against every one of the eleven call sites: the only user-facing removal in v7 is the pip-install input, which no workflow here uses, and the Node 24 requirement in v6 is met because every runner is GitHub-hosted. Four of the five edited files are reachable and will exercise the bump on master; the fifth never runs at all, which is a pre-existing repository defect with an open fix.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | Medium | .github/workflows/ci.yml:3-7 |
One of the five edited workflows never runs. ci.yml triggers on push: branches: [main, develop] and pull_request: branches: [main], and this repository's default branch is master (verified: gh api repos/embeddedos-org/eAI --jq .default_branch → master; .github/STANDARDS.md "Release model" mandates master + release and defines no main). So neither trigger can fire, which is why gh pr checks 37 reports only the assign job — the C/C++ test job whose setup-python@v5 is being bumped at :39 has never executed on this repository's line of development. |
Already covered by the open eAI#39 ("ci: run the build-and-test workflow on master") — do not duplicate. Note the dependency here and rerun this PR once #39 lands. |
| 2 | Low | .github/workflows/ci.yml:36 |
Adjacent, pre-existing: that job pins runs-on: ubuntu-22.04 while the other ten call sites use ubuntu-latest, windows-latest or macos-latest. It is the only pinned-image job in the repository, and ubuntu-22.04 is the oldest hosted image still offered. setup-python@v6 requires Actions Runner ≥ 2.327.1, which that image satisfies today — but a bump that raises the runtime floor is the moment to notice a job sitting on the image most likely to be retired first. |
Out of scope for this PR. Either justify the pin in a comment (if 22.04 is deliberate for a glibc or toolchain reason) or move it to ubuntu-latest in whatever change lands alongside eAI#39. |
Nothing else. The bump is mechanically complete and consistent: all eleven setup-python@v5 occurrences were changed and none remains.
Architecture conformance
Conforms. §21 places CI configuration in the Infrastructure tier; an action version is build-time only and is not a runtime dependency, so §5.1's law is untouched — nothing in eAI's Tier-3 code changes, and nothing below eAI is affected. §17 makes EoSim an adoption primitive and a CI contract, and three of the five edited files (eosim-sanity.yml, qemu-test.yml, simulation-test.yml) are the jobs that install and exercise EoSim; keeping their Python provisioning current is consistent with ADR-013's CI-contract intent. .github/STANDARDS.md names OpenSSF Scorecard, whose Pinned-Dependencies check prefers commit-SHA pins over floating major tags; this repository pins by tag throughout, which is a pre-existing org-wide posture and not this PR's to change.
Proposed changes
Merge as-is. Two follow-ups, neither blocking:
- Land eAI#39 so
ci.ymlis reachable, then rerun this PR's checks so theci.ymlcall site is covered by something before merge rather than after. - Consider finding 2 in that same change.
No fix PR opened: finding 1 belongs to eAI#39 and finding 2 is a judgement call about runner images, not a provable defect.
Verification I ran
- Upstream release notes, both majors crossed. v6.0.0 (2025-09-04) — breaking change is "Upgrade to node 24", requiring Actions Runner ≥ 2.327.1; the rest is additive (
pip-versioninput,.python-versionandPipfileparsing) or bug fixes, one of which is relevant in the right direction: "Change missing cache directory error to warning". v7.0.0 (2026-07-20) — "Migrate to ESM", "Pin SHA commits and update docs", and one removal: "Remove thepip-installinput". Also "Remove EOL Python versions", which upstream applies to its own test fixtures, not to the versions the action can provision. - The one removal, checked against every call site.
grep -rn -A5 "setup-python@" .github/workflows/*.ymlfiltered forpip-install|cache:|cache-dependency-path|architecturereturns nothing — no call site passespip-install, or any cache- or architecture-related input. Every one of the eleven uses onlypython-version. So v7's sole user-facing removal cannot affect this repository. - Runner floor satisfied. Every
runs-on:in the repository resolves to a GitHub-hosted label (ubuntu-22.04,ubuntu-latest,windows-latest,macos-latest, or a matrix of those). No self-hosted runner has to be upgraded first, which is the one way the v6 Node 24 change bites. - Python versions requested are all still provisioned:
3.10,3.11,3.12(eosim-sanity.yml:25,ci.yml:41, and"3.12"at the six other sites). 3.10 is not yet end-of-life, so v7's fixture cleanup does not reach it. - Reachability of each edited file, read from its
on:block:ci.yml—push: [main, develop],pull_request: [main]→ never runs (finding 1).eosim-sanity.yml—schedule: '0 4 * * *'+workflow_dispatch→ runs nightly on the default branch, so it exercises the bump after merge.qemu-test.yml—schedule: '0 5 * * *'+workflow_dispatch→ same.simulation-test.yml—schedule: '0 3 * * *'+workflow_dispatch→ same.video-build.yml—push: branches: [master, main], paths: promo/**, plusreleaseandworkflow_dispatch→ reachable, but only whenpromo/**changes.
So four of five will actually run the new action version; one will not.
- Completeness:
grep -rn "setup-python@" .github/workflows/finds no remaining@v5.
Not checked
- The bump in action. No CI ran on this PR and I did not dispatch any of the three nightly workflows by hand, so I have not observed
setup-python@v7provision an interpreter in this repository. The judgement above rests on the upstream changelogs plus the input audit, not on an execution. - Whether those jobs pass today. The three nightly workflows are
schedule-driven and I did not inspect their recent run history, so I have no baseline for them. Notably, the org has an open eBoot PR (#81, "install EoSim from a tag that exists, not a wheel that never shipped") about the EoSim install step these same workflows use — if that step is broken here too, this bump will not be what fixes or breaks it. Unknown. - Windows and macOS behaviour. v6 includes "Architecture-Specific PATH Management for Python with
--userFlag on Windows"; two call sites arewindows-latest(eosim-sanity.yml:104,qemu-test.yml:63matrix) and two aremacos-latest. Nothing in this repository appeared to depend onpythonLocationor onpip install --user, but I did not audit the shell steps downstream of eachsetup-pythonfor that. - ESM-migration side effects in v7, and
actions/setup-python's own dependency tree. Described upstream as internal; taken on trust. - SHA pinning. Not changed here and not evaluated as a proposal; mentioned only as context for the Scorecard claim in
STANDARDS.md.
Automated architecture review of 950052fc2c22 — 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/setup-python from 5 to 7.
Release notes
Sourced from actions/setup-python's releases.
... (truncated)
Commits
5fda3b9Pin SHA commits and update docs with latest versions (#1338)4ab7e95Merge pull request #1337 from actions/philip-gai/bump-actions-cache-6-2-00f3a009Remove the pip-install input (#1336)f8cf429Migrate to ESM and upgrade dependencies (#1330)54baeeaValidate and retry manifest fetch to prevent silent failures (#1332)c709277Annotation code fix (#1335)6849080remove EOL Python versions and Bumps numpy text fixture (#1333)0903b46Bump certifi from 2020.6.20 to 2024.7.4 in /tests/data (#1328)ece7cb0Fix pip cache error handling on Windows. (#1040)1d18d7aUpdate advanced-usage.md (#811)Dependabot 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)