Code References

Code references show you where each flag's variable keys appear in your source code, linked straight to the line on your Git host, on every flag's detail page. They also power the stale-flag signals that help you find flags safe to clean up.

Plan availability

Code references are available on the Business and Enterprise plans.

How it works (CI push model)

RedPennon does not connect to your repositories or read your code from its servers. Instead, your CI pipeline scans your checked-out working tree with the RedPennon CLI and pushes a snapshot of references to the code references API.

CI checkout ──▶ rp usages (scan working tree) ──▶ POST /v1/code-references ──▶ RedPennon

No source code is stored — only file paths, line numbers, and short matching snippets. Each push is a full snapshot for one repository and branch: references no longer present are marked stale automatically. A repository connection is created the first time CI pushes for it; there is nothing to install or authorise.

Set up

1. Mint an organisation API token. In the app, go to Settings → API tokens (owner or org admin) and create a token. Copy it once and store it as a CI secret (e.g. REDPENNON_API_TOKEN).
2. Add the scan to CI. Pick the tab for your Git host below.
3. Push and view. On the next run, open any flag — the Code references panel lists each occurrence with a deep link to the exact line.

The Settings → Integrations tab lists the repositories that have pushed references. Connections are read-only (auto-created); you can only disconnect a stale one.

GitHub Actions

Drop a .github/workflows/redpennon-usages.yml file. The GitHub Action handles scanning and uploading automatically — GITHUB_REPOSITORY, GITHUB_REF_NAME, and GITHUB_SHA are read from the Actions environment.

name: RedPennon Code References
on:
  push:
    branches: [main]

jobs:
  usages:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: redpennon/cli@v1
        with:
          api-token: ${{ secrets.REDPENNON_API_TOKEN }}
          project: your-project-key

GitLab CI

Install the CLI and call rp publish. GitLab's built-in env vars (GITLAB_CI, CI_PROJECT_PATH, CI_COMMIT_REF_NAME, CI_COMMIT_SHA) are detected automatically — no extra flags needed.

# .gitlab-ci.yml
redpennon-usages:
  stage: .post
  image: node:22-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - npm install -g @redpennon/cli
    - rp publish --project $REDPENNON_PROJECT_KEY --api-token $REDPENNON_API_TOKEN

Store REDPENNON_API_TOKEN and REDPENNON_PROJECT_KEY as CI/CD variables (masked, protected).

Bitbucket Pipelines

The CLI auto-detects Bitbucket from BITBUCKET_WORKSPACE / BITBUCKET_REPO_FULL_NAME / BITBUCKET_BRANCH / BITBUCKET_COMMIT.

# bitbucket-pipelines.yml
pipelines:
  branches:
    main:
      - step:
          name: RedPennon Code References
          image: node:22-alpine
          script:
            - npm install -g @redpennon/cli
            - rp publish --project $REDPENNON_PROJECT_KEY --api-token $REDPENNON_API_TOKEN

Store REDPENNON_API_TOKEN and REDPENNON_PROJECT_KEY as secured variables in repository settings.

rp publish command

rp publish is the unified scan-and-upload command used by non-GitHub pipelines (and useful locally). It combines rp usages with an automatic POST to the ingest API.

rp publish [--project KEY] [--api-token TOKEN] [--provider github|gitlab|bitbucket]
           [--branch BRANCH] [--commit-sha SHA] [--repository owner/repo]
           [--include GLOB ...] [--exclude GLOB ...]

The --provider flag is optional: it is inferred from the CI environment. Pass it explicitly when running outside a recognised CI system or to override detection.

Matching

The scanner detects RedPennon SDK call sites and captures the key argument — it does not need a list of your keys. Defaults cover the Node, Go, and Python SDK shapes (including batch variables([...]) calls). You can tune detection per repository with a .redpennon/config.yml file (clientNames, matchPatterns, includeFiles/excludeFiles). See the CLI usages guide for the full schema.

Keys built dynamically at runtime (e.g. string concatenation) can't be detected, and a key scanned that doesn't exist in the project is reported back as an unknown key rather than recorded.