fix: Uses GITHUB_TOKEN to authenticate the GH action to stop Ratelimits#3471
fix: Uses GITHUB_TOKEN to authenticate the GH action to stop Ratelimits#3471
Conversation
perkinsjr
requested review from
MichaelUnkey,
chronark,
mcstepp and
ogzhanolguncu
as code owners
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Skipped Deployments
|
📝 WalkthroughWalkthroughA new optional Changes
Sequence Diagram(s)sequenceDiagram
participant Workflow
participant InstallAction
participant GoSteps
participant NodeSteps
Workflow->>InstallAction: Run with github_token input
InstallAction->>GoSteps: Set GITHUB_TOKEN env (if github_token provided)
InstallAction->>NodeSteps: Set GITHUB_TOKEN and NPM_TOKEN env (if github_token provided)
GoSteps-->>InstallAction: Perform authenticated Go operations
NodeSteps-->>InstallAction: Perform authenticated Node operations
InstallAction-->>Workflow: Complete installation
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Thank you for following the naming conventions for pull request titles! 🙏 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🔭 Outside diff range comments (2)
.github/workflows/job_test_go_api_local.yaml (1)
15-22: Tighten default permissionsThis job now needs the token only for dependency resolution.
Add an explicit, least-privilegepermissions:block (e.g.contents: read, packages: read) to avoid the default write scopes that come with${{ secrets.GITHUB_TOKEN }}.jobs: tests: permissions: contents: read packages: read.github/workflows/deploy_trigger.yaml (1)
9-12: Duplicateactions/checkout@v4step – remove the second invocation
The workflow checks the repo out twice in succession. Unless you need a fresh checkout after an earlier cache-clearing step (none exists), the extra call is redundant and adds ~7-10 s to every run.- - uses: actions/checkout@v4 - - - uses: actions/checkout@v4 + - uses: actions/checkout@v4
♻️ Duplicate comments (6)
.github/workflows/job_test_unit.yaml (1)
26-32: Same permission hardening recommendation as other test jobsConsider adding a minimal
permissions:block for this job; it currently inherits the expansive defaults..github/workflows/job_test_api_staging.yaml (1)
37-42: Same permission hardening recommendation as other test jobsLock token scopes to
contents: readandpackages: readto prevent privilege creep..github/workflows/job_test_agent_local.yaml (1)
13-16: Same token-leak concern as intest_agent_local.yamlReuse the outcome of the audit requested above; no further action if the composite is already safe.
.github/workflows/job_test_api_local.yaml (1)
19-25: Token-leak audit applies here as wellThe comment made for
test_agent_local.yamlequally applies to this workflow..github/workflows/job_clickhouse_migration_production.yaml (1)
18-26: Re-check composite action for secret leakageSame audit request as earlier: ensure
.github/actions/installnever prints the token value..github/workflows/job_test_api_canary.yaml (1)
32-36: Token secrecy auditAudit the composite action for accidental token echoing, as noted in prior comments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (23)
.github/actions/install/action.yaml(5 hunks).github/workflows/autofix.ci.yaml(1 hunks).github/workflows/build.yaml(2 hunks).github/workflows/changesets.yaml(2 hunks).github/workflows/check_quotas.yml(1 hunks).github/workflows/deploy_trigger.yaml(1 hunks).github/workflows/job_clickhouse_migration_preview.yaml(1 hunks).github/workflows/job_clickhouse_migration_production.yaml(1 hunks).github/workflows/job_deploy_api_canary.yaml(3 hunks).github/workflows/job_deploy_api_enterprise.yaml(2 hunks).github/workflows/job_deploy_api_production.yaml(1 hunks).github/workflows/job_deploy_api_staging.yaml(3 hunks).github/workflows/job_deploy_logdrain_production.yaml(1 hunks).github/workflows/job_deploy_workflows.yaml(2 hunks).github/workflows/job_test_agent_integration.yaml(1 hunks).github/workflows/job_test_agent_local.yaml(1 hunks).github/workflows/job_test_api_canary.yaml(1 hunks).github/workflows/job_test_api_local.yaml(1 hunks).github/workflows/job_test_api_staging.yaml(1 hunks).github/workflows/job_test_go_api_local.yaml(1 hunks).github/workflows/job_test_unit.yaml(1 hunks).github/workflows/release.yaml(1 hunks).github/workflows/test_agent_local.yaml(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
.github/workflows/job_clickhouse_migration_production.yaml (2)
Learnt from: chronark
PR: unkeyed/unkey#3161
File: go/pkg/clickhouse/schema/databases/001_verifications/002_raw_key_verifications_v1.sql:31-33
Timestamp: 2025-04-22T14:40:51.459Z
Learning: The ClickHouse table schemas in the codebase mirror the production environment and cannot be modified directly in PRs without careful migration planning.
Learnt from: chronark
PR: unkeyed/unkey#3161
File: go/pkg/clickhouse/schema/databases/002_ratelimits/006_ratelimits_per_day_v1.sql:1-13
Timestamp: 2025-04-22T14:43:11.724Z
Learning: In the unkey project, the SQL files in clickhouse/schema/databases represent the current production schema and shouldn't be modified directly in PRs. Schema changes require dedicated migration scripts.
.github/workflows/job_deploy_api_staging.yaml (1)
Learnt from: Devansh-Baghel
PR: unkeyed/unkey#2452
File: oss.gg/7_create_a_template.md:42-42
Timestamp: 2024-10-15T19:57:16.520Z
Learning: In projects using Cloudflare Workers, the `wrangler.toml` file in the project root is the configuration file.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Test Packages / Test ./packages/nextjs
- GitHub Check: Test Packages / Test ./packages/hono
- GitHub Check: Test Packages / Test ./internal/keys
- GitHub Check: Test Packages / Test ./packages/cache
- GitHub Check: Test Packages / Test ./internal/clickhouse
- GitHub Check: autofix
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (22)
.github/actions/install/action.yaml (1)
91-94: Verify that re-using the GitHub token asNPM_TOKENactually works
NPM_TOKENusually expects an npm-registry auth token, not a GitHub Actions token.
If your packages are hosted on GH Packages this is fine; otherwise the install step will start 401-ing and, worse, the GitHub token could get copied into.npmrc.Please double-check the registry and adjust if required.
.github/workflows/release.yaml (1)
23-28: Looks good – release workflow correctly forwards the token
No additional issues spotted with the new input wiring in this file..github/workflows/deploy_trigger.yaml (2)
14-15: ✅ Token wired through correctly
Passing${{ secrets.GITHUB_TOKEN }}to theinstallaction is the right move now that the composite action supports authenticated installs.
21-22: Verify working-directory path
apps/billinglooks sensible, but because the step is executed from the repo root after a mono-repo install it’s easy to fat-finger. Just double-check the folder exists (case-sensitive) to avoid silent no-op failures..github/workflows/job_deploy_api_production.yaml (1)
19-19: ✅ Authenticated install enabled
github_tokenpassed – keepspnpm/gomodule downloads behind the token and avoids rate-limit pain..github/workflows/job_deploy_logdrain_production.yaml (1)
19-19: ✅ Token forwarding looks good
Nothing else to flag..github/workflows/job_test_agent_integration.yaml (1)
19-19: ✅ Install step now authenticated
Should cut down on flakygoproxy 403s in long integration runs..github/workflows/check_quotas.yml (1)
26-26: ✅ Cron job will now install with proper auth
Good addition; scheduled workflows previously had a higher chance of hitting anonymous rate limits..github/workflows/test_agent_local.yaml (1)
13-16: Confirm the install action keeps the token secretThe new
github_tokeninput is useful for authenticated installs, but please double-check that.github/actions/installdoes not writeinputs.github_token(orenv.GITHUB_TOKEN) to stdout/stderr, as that would leak the secret.
Consider addingshell: bash --noprofile --norc -euo pipefailandset -xavoidance inside the composite to be safe..github/workflows/changesets.yaml (1)
26-26: Token forwarding looks correctPassing the repository token to the custom
installaction is consistent with the new input signature.
No further concerns here..github/workflows/build.yaml (2)
5-7: Adequate permission scope
contents: readis sufficient for a pure build workflow that does not push artifacts back to GitHub.
👍
22-22: OK – token propagated to install stepMatches the composite action’s new
github_tokeninput. Nothing else to flag..github/workflows/job_deploy_api_enterprise.yaml (2)
4-6: Whitespace-only tweak – no action needed
28-28: Verify secret availability when invoked viaworkflow_call
secrets.GITHUB_TOKENis automatically provided, but its default permission set is read.
If the install action (or downstream tools likepnpm) require write access (e.g., to hit private registries withnpm publish), you must explicitly elevate the permission in the caller workflow.Confirm the caller grants at least:
permissions: contents: read # or write, if needed by install action.github/workflows/autofix.ci.yaml (1)
26-26: Token correctly forwarded to install actionLooks good.
.github/workflows/job_deploy_api_staging.yaml (3)
4-6: No functional change – formatting only
19-19: Token passthrough OKMatches the composite action interface.
28-28: 👍 Secret forwarded to deployment stepEnsures the deploy command can authenticate with Cloudflare.
.github/workflows/job_deploy_api_canary.yaml (1)
19-20: Token now forwarded to install action – LGTMPassing the GitHub token enables authenticated
pnpm,go, ornpminstalls inside the composite action. No further comments..github/workflows/job_clickhouse_migration_preview.yaml (1)
20-20: Authenticated install step looks correctForwarding
github_tokenkeeps this job consistent with the other workflows. 👍.github/workflows/job_deploy_workflows.yaml (2)
22-22: Verify build filter path
./apps/workflowsreplaces the previous./apps/logdrain. Ensure:
- The
workflowsapp exists in the monorepo.- Its
package.jsonhas the correct build script invoked by turbo.If either is missing, this step will noop or fail the job.
26-28: Working-directory update mirrors build change – LGTMDirectory switch to
apps/workflowsaligns with the new build target.
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/autofix.ci.yaml(1 hunks).github/workflows/changesets.yaml(2 hunks).github/workflows/job_clickhouse_migration_preview.yaml(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions. No additional configuration is needed for this automatic masking behavior.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: The `sensitive` property is not supported for GitHub Actions composite action inputs - it's only available for reusable workflow inputs. Composite action inputs don't have a `sensitive` attribute in their schema.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: The `sensitive` property is not supported for GitHub Actions composite action inputs - it's only available for reusable workflow inputs using `workflow_call`. Attempting to use `sensitive: true` in composite action inputs results in a schema validation error "Property sensitive is not allowed. (yaml-schema: GitHub Action 513)".
.github/workflows/changesets.yaml (2)
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions. No additional configuration is needed for this automatic masking behavior.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions.
.github/workflows/autofix.ci.yaml (4)
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions. No additional configuration is needed for this automatic masking behavior.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: The `sensitive` property is not supported for GitHub Actions composite action inputs - it's only available for reusable workflow inputs using `workflow_call`. Attempting to use `sensitive: true` in composite action inputs results in a schema validation error "Property sensitive is not allowed. (yaml-schema: GitHub Action 513)".
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: The `sensitive` property is not supported for GitHub Actions composite action inputs - it's only available for reusable workflow inputs. Composite action inputs don't have a `sensitive` attribute in their schema.
.github/workflows/job_clickhouse_migration_preview.yaml (2)
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions. No additional configuration is needed for this automatic masking behavior.
Learnt from: perkinsjr
PR: unkeyed/unkey#3471
File: .github/actions/install/action.yaml:9-12
Timestamp: 2025-07-07T19:45:10.498Z
Learning: GitHub Actions automatically masks tokens in logs when they come from secrets (like `${{ secrets.GITHUB_TOKEN }}`) or match recognized token patterns, regardless of any explicit sensitive marking in composite actions.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: Test Packages / Test ./packages/rbac
- GitHub Check: Test Packages / Test ./packages/cache
- GitHub Check: Test Packages / Test ./packages/nextjs
- GitHub Check: Test Packages / Test ./internal/keys
- GitHub Check: Test Packages / Test ./internal/clickhouse
- GitHub Check: Test Packages / Test ./internal/resend
- GitHub Check: Test Packages / Test ./packages/api
- GitHub Check: Test Packages / Test ./internal/billing
- GitHub Check: autofix
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (5)
.github/workflows/changesets.yaml (2)
11-13: Permissions correctly updated to write – resolves prior blocker
The workflow can now push commits, tags, and open PRs as required bychangesets/action.
27-27: Confirmgithub_tokeninput is recognised by the install action
If.github/actions/install/action.yamlhas not been published with a matchinginputs.github_token, the workflow will fail schema-validation at runtime..github/workflows/autofix.ci.yaml (2)
18-18: Usestoken:input forsetup-node– perfect
This change fixes the authentication gap flagged in the previous review.
24-24: Same token propagation caveat as above
Double-check the composite install action’s input contract to avoid “unexpected named parameter” errors..github/workflows/job_clickhouse_migration_preview.yaml (1)
20-20: Token now passed to install action
Consistent with other workflows – OK as long as the action expects it.
perkinsjr
changed the title
| description: Whether to install Go and dependencies | ||
| ts: | ||
| description: Whether to install Node.js and dependencies | ||
| github_token: |
There was a problem hiding this comment.
this should be a secret, not an input
There was a problem hiding this comment.
see .github/workflows/job_deploy_workflows.yaml as an example for passing secrets
There was a problem hiding this comment.
This is exactly how that works? WYM use a secret.
There was a problem hiding this comment.
you're passing it in as an input which might not get redacted in logs properly, use a secretinstead like in the workflow above
|
It's already redacted? This is passed to the logs as ******** |
|
As you can see in the logs right here. |
|
I don't make the rules |
|
I don't understand. I am using secret and passing it as the input? this is exactly what I am doing... IN THIS PR EXAMPLE |
|
This isn't a secret we are giving to Github... This secret is accessible anywhere in a runner? so you want me to secret a internal secret? |
|
you’re defining the variable as a regular input, not as a secret |
|
it should be |
|
it probably doesn’t make a big difference, but if this ever gets leaked for whatever reason cause we didn’t do it properly according to their docs, while knowing about it, we’re fucked |
|
Not according to GitHub documentation it is not. Or when using their official runners |
|
|
we’re talking about 2 different things |
|
No we aren't? The providing side provides it a secret (e.g any job that is calling it), the receiving side receives it as a redacted... The one time use token is then destroyed? This would be the same for a published example like Checkout or autofix CI |
|
I gave my feedback, do with that what you want |
|
we’re debating about a 1 line change that has no downside |
|
I haven’t dug too deep in to their docs |
|
if thisi s what they recommend, it should be fine |
|
I just see us using a secret and know there’ s an actual |
|
It's not a 1 line change. This is a composite action which don't have secrets. They are received via the inputs, which is why on the other side they are passed as a secret to the composite action as a redacting in the logs. This is also why every single file of ours has a permission in it to make sure the code is trusted and can't be executed. I am happy to let you read up on composite actions etc before we merge. |
|
I will also happily rewrite our CI to use Reusuable workflows instead, if you want to use secrets directly. |
|
oh so there’s a difference between actions and workflows.. TIL |
2 participants
What does this PR do?
GITHUB_TOKENprovides authenticated access to GitHub APIs, significantly increasing rate limits. It's deleted everytime the job is successful or the job hits 24h and a new one is issued.Type of change
How should this be tested?
RIP some PR's and see what happens. I am assuming that GITHUB_TOKEN's work like PATs
Checklist
Required
pnpm buildpnpm fmtconsole.logsgit pull origin mainAppreciated
Summary by CodeRabbit