GITHUB SECRETS MIGRATION: migrate writer/writer-framework to Infisical - #1290
GITHUB SECRETS MIGRATION: migrate writer/writer-framework to Infisical#1290giusepperrr wants to merge 1 commit into
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
📝 WalkthroughWalkthroughThis PR updates two GitHub Actions workflows to fetch secrets through Infisical, adds explicit workflow permissions, and switches publish and dispatch steps to use environment-backed values instead of direct secret references. ChangesWorkflow secret sourcing and dispatch
Sequence Diagram(s)sequenceDiagram
participant PublishJob as publish.yml trigger-agent-manager job
participant TriggerWorkflow as trigger-workflow.yml trigger agent manager job
participant Infisical as Infisical
participant GitHubAPI as GitHub dispatches API
PublishJob->>TriggerWorkflow: calls workflow with INFISICAL_* secrets
TriggerWorkflow->>Infisical: fetches AGENT_MANAGER_PAT and workflow secrets
Infisical-->>TriggerWorkflow: returns AGENT_MANAGER_PAT
TriggerWorkflow->>GitHubAPI: sends dispatches request with Bearer AGENT_MANAGER_PAT
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Around line 39-47: Move the Infisical secret fetches in publish workflow
closer to where they are used so the tokens are not exposed for the whole job.
In the publish job, refactor the secret-loading step that uses infisical-secrets
to fetch LAUNCHDARKLY_ACCESS_TOKEN only before the build-related step that needs
it and PYPI_TOKEN only immediately before the publish/upload step, or scope them
via step outputs/env if supported. Keep the existing publish job flow intact
while limiting token lifetime around the relevant consumer steps.
In @.github/workflows/trigger-workflow.yml:
- Around line 69-75: The dispatch step currently can succeed even when
AGENT_MANAGER_PAT is missing or rejected, so the workflow may look successful
while the agent-manager trigger never happened. In the trigger-workflow.yml
dispatch block, add a guard before the curl call to verify AGENT_MANAGER_PAT is
present, and change the curl invocation to fail the job on non-2xx HTTP
responses by checking the returned status from the dispatch request. Keep the
fix localized to the dispatch logic that uses repo_owner, repo_name, event_type,
merged_payload, and AGENT_MANAGER_PAT.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6c2a5225-ea56-40d4-8176-4667f1d62326
📒 Files selected for processing (2)
.github/workflows/publish.yml.github/workflows/trigger-workflow.yml
| - name: Fetch secrets from Infisical | ||
| uses: WriterInternal/devops-github-actions/infisical-secrets@cf0625c0cb6646c057b9bc81c49c8554b2313e27 # v2.3.0 | ||
| with: | ||
| org-identity-id: ${{ secrets.INFISICAL_ORG_IDENTITY_UUID }} | ||
| org-project-slug: ${{ secrets.INFISICAL_ORG_PROJECT_SLUG }} | ||
| repo-identity-id: ${{ secrets.INFISICAL_REPO_IDENTITY_UUID }} | ||
| repo-project-slug: ${{ secrets.INFISICAL_REPO_PROJECT_SLUG }} | ||
| env-slug: prod | ||
| required-keys: LAUNCHDARKLY_ACCESS_TOKEN PYPI_TOKEN |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Fetch publish secrets closer to their consumers.
This step exports both LAUNCHDARKLY_ACCESS_TOKEN and PYPI_TOKEN before dependency install/build commands run, broadening token exposure beyond the upload/publish steps. Prefer fetching each token immediately before the step that needs it, or use step-scoped outputs/env if the composite action supports that.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish.yml around lines 39 - 47, Move the Infisical
secret fetches in publish workflow closer to where they are used so the tokens
are not exposed for the whole job. In the publish job, refactor the
secret-loading step that uses infisical-secrets to fetch
LAUNCHDARKLY_ACCESS_TOKEN only before the build-related step that needs it and
PYPI_TOKEN only immediately before the publish/upload step, or scope them via
step outputs/env if supported. Keep the existing publish job flow intact while
limiting token lifetime around the relevant consumer steps.
| curl -L \ | ||
| -X POST \ | ||
| -H "Accept: application/vnd.github+json" \ | ||
| -H "Authorization: Bearer ${{ secrets.AGENT_MANAGER_PAT }}" \ | ||
| -H "Authorization: Bearer $AGENT_MANAGER_PAT" \ | ||
| -H "X-GitHub-Api-Version: 2022-11-28" \ | ||
| https://api.github.com/repos/$repo_owner/$repo_name/dispatches \ | ||
| -d "{\"event_type\": \"$event_type\", \"client_payload\": $merged_payload}" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Fail the job when the dispatch API rejects the migrated PAT.
If Infisical returns a missing/mis-scoped AGENT_MANAGER_PAT, GitHub can respond with 401/403 while curl still exits successfully. Add an explicit token guard and HTTP failure handling so the release does not appear successful when the agent-manager dispatch was skipped.
Suggested hardening
+ : "${AGENT_MANAGER_PAT:?AGENT_MANAGER_PAT was not populated by Infisical}"
+
- curl -L \
+ curl --fail --show-error --silent -L \
-X POST \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $AGENT_MANAGER_PAT" \#!/bin/bash
# Verify the dispatch curl invocation has explicit HTTP failure handling.
fd -i 'trigger-workflow.yml' .github/workflows --exec awk 'NR>=69 && NR<=75 {print NR ":" $0}' {}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/trigger-workflow.yml around lines 69 - 75, The dispatch
step currently can succeed even when AGENT_MANAGER_PAT is missing or rejected,
so the workflow may look successful while the agent-manager trigger never
happened. In the trigger-workflow.yml dispatch block, add a guard before the
curl call to verify AGENT_MANAGER_PAT is present, and change the curl invocation
to fail the job on non-2xx HTTP responses by checking the returned status from
the dispatch request. Keep the fix localized to the dispatch logic that uses
repo_owner, repo_name, event_type, merged_payload, and AGENT_MANAGER_PAT.
Summary
Automated Infisical migration PR (orchestrator opened after verifier gate).
Harness contract:
composite-v2, centralized compositecf0625c0cb66(v2.3.0). If the composite SHA has advanced past this, this PR may be drifted — re-verify against the current contract before merge.Summary by CodeRabbit