chore(deps): update actions/setup-python action to v7

[open-turo-bot]

This PR contains the following updates:

Package	Type	Update	Change
actions/setup-python	action	major	v6 -> v7

---

Release Notes

actions/setup-python (actions/setup-python)

v7

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[github-actions]

Release notes preview

No new release will be created.

If you are expecting a release, you will need to either fix a bug or add a feature.
Chores, CI, docs, refactoring, style and other changes will not trigger a release.

[semgrep-app]

Semgrep identified an issue in your code:

actions/setup-python@v7 follows a mutable tag, so this workflow may execute changed action code if v7 is repointed. A compromised or retagged action could run in test-pre-installed and steal repository data or CI credentials.

More details about this

actions/setup-python@v7 in the Setup python step is only pinned to the v7 tag, so this job will run whatever code that tag points to at execution time. If someone who can publish or retag actions/setup-python moves v7 to a malicious release, this workflow would download and execute that new action on ubuntu-latest before pip install pre-commit, letting it read the checked-out repository, steal GITHUB_TOKEN or other job secrets, and send them out over the network.

A plausible attack flow here is: 1) an attacker compromises the action publisher or release process for actions/setup-python; 2) they repoint v7 to code that looks normal but adds a step to exfiltrate environment variables; 3) your test-pre-installed job reaches uses: actions/setup-python@v7 and runs the attacker's code; 4) that code can access the workspace created after actions/checkout@v7, inspect repository contents, and use available credentials to tamper with CI behavior or access other systems tied to this workflow.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: actions/setup-python@v7
	uses: actions/setup-python@42375524c7d973b1c34b2f43362901d2b83bc45f # setup-python v7

View step-by-step instructions

1. Replace the version tag in the workflow step with the full commit SHA for the exact actions/setup-python release you want to use.
   Change uses: actions/setup-python@v7 to uses: actions/setup-python@<40-character-commit-sha>.

2. Keep the action version intent clear by pinning to the commit that corresponds to the current v7 release, for example from the actions/setup-python release page or repository tags.

3. Add a short comment next to the pinned reference if helpful, such as # setup-python v7, so future updates are easier while still keeping the action immutable. Pinning to a commit SHA prevents the referenced action code from changing unexpectedly.

Alternatively, if you need easier dependency updates, use a tool such as Dependabot to update uses: actions/setup-python@<sha> automatically while still keeping the workflow pinned to a specific commit.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by unpinned-github-action-strict.

_{You can view more details about this finding in the Semgrep AppSec Platform.}