Remove obsolete warlock private-git-dependency CI steps#185
Merged
sarahxsanders merged 2 commits intoJun 15, 2026
Conversation
@posthog/warlock is now published to npm (package.json pins ^0.2.2 and pnpm-lock.yaml resolves it from the registry), so the CI runner no longer needs GitHub App credentials to clone it as a private git dependency. Remove the now-obsolete `Generate token for private dependencies` and `Configure git auth for private deps` steps (and their stale TODO comment) from build.yml and build-release.yml. These steps fail on forked PRs because GitHub does not pass repo/org secrets to forks, so `app-id` resolves empty and the action throws (`Input required and not supplied: app-id`) before the build runs. Removing them honors the steps' own TODO and unblocks fork CI. The unrelated skills-repo token step (build-release.yml) and wizard-ci token step (wizard-ci-trigger.yml) are left untouched, as is the Scan skills with Warlock security-scan step, which never needed git auth. Generated-By: PostHog Code Task-Id: 0d9df375-0b9d-42c7-b35f-7f335b65634d
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
Fork PRs don't receive repo secrets, so Warlock can't reach the LLM gateway to triage matches and ends up reporting every hit (including false positives) as a threat, failing the build. Mark the scan step continue-on-error when the PR head is a fork. The scan still runs and posts its annotations on the diff for maintainer review, but a failure no longer blocks the check. Trusted runs (main-repo PRs, push-to-main, release) have the secret, so fork == false and the scan remains a hard gate with full LLM triage — the real release gate is unchanged. Generated-By: PostHog Code Task-Id: 0d9df375-0b9d-42c7-b35f-7f335b65634d
gewenyu99
approved these changes
Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Makes CI pass on forked PRs, in two parts:
Generate token for private dependenciesandConfigure git auth for private depssteps (plus their staleTODOcomment) frombuild.ymlandbuild-release.yml.Scan skills with Warlockstep non-blocking on fork PRs inbuild.yml, viacontinue-on-error: ${{ github.event.pull_request.head.repo.fork == true }}.Why — remove the private-git-dep steps
@posthog/warlockis now published to npm —package.jsonpins^0.2.2andpnpm-lock.yamlresolves it from the registry (sha512 integrity hash, not a git URL). The CI runner no longer needs GitHub App credentials to clone it as a private git dependency, which is exactly what these two steps did.These steps fail on forked PRs: GitHub does not pass repo/org secrets to fork workflows, so
secrets.GH_APP_POSTHOG_WIZARD_CI_BOT_APP_IDresolves empty and the action throws before anything builds:The steps' own comment already said to remove them once warlock was published:
So this honors that TODO.
Why — make the scan non-blocking on forks
Removing the steps above clears the
app-idfailure but exposes a second fork issue: theScan skills with Warlockstep needsCONTEXT_MILL_WARLOCK_POSTHOG_PERSONAL_KEYto reach the LLM gateway for triage. Forks don't get that secret, so the scan can't triage and reports every match (including false positives) as a threat → the build fails. Warlock is noisy against this repo's own skill docs, so fork contributors would routinely hit red builds they can't do anything about.Scoping
continue-on-errorto forks fixes this:false, so the scan stays a hard gate with full LLM triage.It is scoped to that single step — install, build, lint, and bundle-size checks all still block the build normally on forks.
Review workflow this implies
Fork PR scans become advisory: a maintainer reviews the Warlock annotations on the diff as part of normal review. Nothing unsafe can ship, because the full triaged scan still gates
build-release(on merge to main, where the secret exists). If contribution volume ever makes manual triage annoying, the proper next step is an approval-gated workflow — intentionally out of scope here.Left untouched (intentionally)
build-release.yml→Generate skills repo token(SKILLS_PUSH_APP_ID) — unrelated; pushes generated plugins toskills/ai-plugin.wizard-ci-trigger.yml→Generate GitHub App token— unrelated; handles the/wizard-cicommand.Scan skills with Warlockstep still runs in both workflows — it's the actual security scan, and stays a hard gate everywhere except fork PRs.🤖 Generated with Claude Code