chore: update GitHub Actions for Node 24

[marandaneto]

💡 Motivation and Context

Update the remaining workflow actions that still target older Node runtimes, and make the uv setup deterministic by declaring a required version in pyproject.toml.

💚 How did you test it?

• Parsed .github/workflows/release.yml, .github/workflows/ci.yml, and .github/workflows/generate-references.yml with Ruby YAML.load_file
• Parsed pyproject.toml with uv run python
• Ran git diff --check

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file
• Added the release label to the PR

[greptile-apps]

Security Review

• Supply chain / unpinned Actions (.github/workflows/release.yml): actions/checkout@v6, actions/setup-python@v6, actions/create-github-app-token@v3, and actions/cache@v5 are referenced by mutable floating tags instead of commit SHAs. This workflow holds contents: write, actions: write, and id-token: write permissions and accesses secrets for PyPI OIDC publishing, the GitHub App releaser private key, and Slack tokens. A tag mutation or compromised action maintainer account could result in secret exfiltration or an unauthorized release.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 32

Comment:
**Floating tags in security-sensitive workflow**

`release.yml` upgrades to `@v6` using mutable floating tags, while `ci.yml` and `generate-references.yml` consistently pin all actions to specific commit SHAs (e.g. `actions/checkout@85e6279...`). This workflow has elevated permissions (`contents: write`, `actions: write`, `id-token: write`) and accesses multiple secrets for PyPI publishing and the GitHub App releaser token, making it the highest-priority workflow to harden against supply-chain attacks.

The same issue applies to `actions/setup-python@v6` (line 99), `actions/create-github-app-token@v3` (line 86), `actions/cache@v5` (line 117), and `actions/checkout@v6` on line 236.

Consider pinning each action to its full commit SHA (with the tag in a comment for readability), matching the pattern already used in the other two workflows.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "chore: update GitHub Actions for Node 24" | Re-trigger Greptile}

[greptile-apps]

Floating tags in security-sensitive workflow

release.yml upgrades to @v6 using mutable floating tags, while ci.yml and generate-references.yml consistently pin all actions to specific commit SHAs (e.g. actions/checkout@85e6279...). This workflow has elevated permissions (contents: write, actions: write, id-token: write) and accesses multiple secrets for PyPI publishing and the GitHub App releaser token, making it the highest-priority workflow to harden against supply-chain attacks.

The same issue applies to actions/setup-python@v6 (line 99), actions/create-github-app-token@v3 (line 86), actions/cache@v5 (line 117), and actions/checkout@v6 on line 236.

Consider pinning each action to its full commit SHA (with the tag in a comment for readability), matching the pattern already used in the other two workflows.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 32

Comment:
**Floating tags in security-sensitive workflow**

`release.yml` upgrades to `@v6` using mutable floating tags, while `ci.yml` and `generate-references.yml` consistently pin all actions to specific commit SHAs (e.g. `actions/checkout@85e6279...`). This workflow has elevated permissions (`contents: write`, `actions: write`, `id-token: write`) and accesses multiple secrets for PyPI publishing and the GitHub App releaser token, making it the highest-priority workflow to harden against supply-chain attacks.

The same issue applies to `actions/setup-python@v6` (line 99), `actions/create-github-app-token@v3` (line 86), `actions/cache@v5` (line 117), and `actions/checkout@v6` on line 236.

Consider pinning each action to its full commit SHA (with the tag in a comment for readability), matching the pattern already used in the other two workflows.

How can I resolve this? If you propose a fix, please make it concise.

[github-actions]

posthog-python Compliance Report

Date: 2026-04-16 16:04:55 UTC
Duration: 160001ms

✅ All Tests Passed!

30/30 tests passed

---

Capture Tests

✅ 29/29 tests passed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	516ms
Format Validation.Event Has Uuid	✅	1506ms
Format Validation.Event Has Lib Properties	✅	1506ms
Format Validation.Distinct Id Is String	✅	1506ms
Format Validation.Token Is Present	✅	1505ms
Format Validation.Custom Properties Preserved	✅	1506ms
Format Validation.Event Has Timestamp	✅	1506ms
Retry Behavior.Retries On 503	✅	9513ms
Retry Behavior.Does Not Retry On 400	✅	3510ms
Retry Behavior.Does Not Retry On 401	✅	3506ms
Retry Behavior.Respects Retry After Header	✅	9514ms
Retry Behavior.Implements Backoff	✅	23528ms
Retry Behavior.Retries On 500	✅	7500ms
Retry Behavior.Retries On 502	✅	7517ms
Retry Behavior.Retries On 504	✅	7511ms
Retry Behavior.Max Retries Respected	✅	23529ms
Deduplication.Generates Unique Uuids	✅	1497ms
Deduplication.Preserves Uuid On Retry	✅	7515ms
Deduplication.Preserves Uuid And Timestamp On Retry	✅	14513ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	7511ms
Deduplication.No Duplicate Events In Batch	✅	1508ms
Deduplication.Different Events Have Different Uuids	✅	1507ms
Compression.Sends Gzip When Enabled	✅	1507ms
Batch Format.Uses Proper Batch Structure	✅	1507ms
Batch Format.Flush With No Events Sends Nothing	✅	1005ms
Batch Format.Multiple Events Batched Together	✅	1505ms
Error Handling.Does Not Retry On 403	✅	3509ms
Error Handling.Does Not Retry On 413	✅	3507ms
Error Handling.Retries On 408	✅	7514ms

Feature_Flags Tests

✅ 1/1 tests passed

View Details

Test	Status	Duration
Request Payload.Request With Person Properties Device Id	✅	515ms