ci: stop release-please self-triggering loop on its own branch

[arcjet-rei]

Problem

The arcjet-arcjet-js-release-please[bot] has been stuck in a self-triggering loop, force-pushing a fresh chore: Release 1.6.0 commit to release-please--branches--main roughly once a minute for ~9 hours — hundreds of cancelled Push workflow runs.

Root cause

Two individually-reasonable changes are fatal together:

• chore: always trigger workflows on release-please branch #5998 added release-please--branches--main to push.yml's branches: trigger.
• chore: configure release-please to use GitHub App Token #6019 switched the token from GITHUB_TOKEN to a GitHub App installation token.

Pushes made with GITHUB_TOKEN do not re-trigger workflows (GitHub's loop guard), but App-token pushes do. So:

release-please force-pushes release branch (App token)
  → push event on release-please--branches--main
    → push.yml runs the `release` job again
      → release-please regenerates the commit + force-pushes (new SHA)
        → push event again → ∞

This stayed dormant after #6019 (May 5) until the 1.6.0 release cycle opened a release PR for the loop to thrash against.

Fix

Gate the release job to main only — it never needs to run when its own PR branch is pushed. This preserves both prior intents: the test and examples jobs still run on the release branch (#5998), and the App token still authors the release (#6019).

Once merged, the push to main runs the release job once normally, then any further push to the release branch skips it → loop broken.

Note

The loop is still running. Until this lands, consider disabling the Push workflow or closing the 1.6.0 release PR to stop burning Actions minutes.

🤖 Generated with Claude Code

[arcjet-review]

Arcjet Review — 🔴 High Risk

Decision: Reviewers Assigned

Rationale: This PR changes a GitHub Actions workflow and includes token-related release automation behavior, which triggers CI/CD and authentication-related escalation criteria. The actual code change is small and appears intended to prevent Release Please from self-triggering on its generated branch by limiting the release job to refs/heads/main. I did not identify hardcoded secrets or direct security vulnerabilities in the diff, but CI/CD changes involving GitHub App token behavior should receive human review. No specific escalation reviewers are configured.

Summary of Changes

Adds a job-level condition to the Release Please job in .github/workflows/push.yml so it only runs on main, preventing the release branch from repeatedly triggering itself while allowing other jobs to continue running on that branch.

Escalation Triggers

• CI/CD Pipeline: The PR modifies .github/workflows/push.yml, a GitHub Actions workflow file.
• Authentication & Authorization: The diff references GitHub App token and GITHUB_TOKEN behavior in the release automation path.

Review Focus Areas

• Confirm that restricting the release job to github.ref == 'refs/heads/main' is correct for all workflow trigger types used by this workflow.
  If this workflow also runs on events where github.ref differs from refs/heads/main, Release Please may stop running unexpectedly.
• Verify that the release branch still gets the intended test and examples jobs, and that no release-specific validation is accidentally skipped.
  The comment says only the release job should be skipped on the release branch; human reviewers should confirm the workflow structure matches that expectation.
• Confirm the GitHub App token is scoped only to the permissions needed for Release Please and cannot unintentionally trigger privileged workflow paths.
  App token pushes can retrigger workflows, so token permissions and workflow conditions are important to prevent automation loops or privilege expansion.

Notes

The diff is very small and appears targeted, but CI/CD workflow changes involving token-triggered automation are high-risk under the configured review policy and should be reviewed by a human.

_{Review: eafc38e6 | Model: openai/gpt-5.5 | Powered by Arcjet Review}