Author and manage workflows

Configure workflow triggers and events

The on: key decides when a workflow runs. It accepts a single event, a list, or a map of events with activity types and filters. A workflow runs once per matching event — two matching events mean two runs.

flowchart TD
  Q["What should start the run?"]
  Q --> A1["Code or PR activity"] --> T1["push · pull_request<br/>with branches, paths, types"]
  Q --> A2["A clock"] --> T2["schedule<br/>cron, UTC unless timezone is set"]
  Q --> A3["A person, on demand"] --> T3["workflow_dispatch<br/>typed inputs, Run workflow button"]
  Q --> A4["Another system"] --> T4["repository_dispatch<br/>event_type and client_payload"]
  Q --> A5["Another workflow, as a job"] --> T5["workflow_call<br/>inputs, secrets, outputs"]
  Q --> A6["Another workflow finishing"] --> T6["workflow_run<br/>types: completed"]

Repository events and filters

on:
  push:
    branches: [main, 'release/**']
    tags: ['v*']
    paths-ignore: ['docs/**', '**.md']
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main]
  schedule:
    - cron: '30 5 * * 1-5'          # 05:30 on weekdays
      timezone: 'Europe/Madrid'     # optional; UTC without it
  issues:
    types: [labeled]
  release:
    types: [published]

Glob patterns use * (no /), ** (any depth), ?, + and []. A branch filter on pull_request matches the base branch of the pull request, not the head.

Scheduled workflows

• POSIX cron with five fields — minute, hour, day of month, month, day of week — and *, ,, -, /. Shorthand such as @daily is not supported.
• UTC by default; an optional timezone key takes an IANA zone name.
• The shortest interval is every 5 minutes, and runs can be delayed — or dropped — under load, especially at the top of the hour. Pick an odd minute.
• Runs on the latest commit of the default branch only.
• In public repositories, scheduled workflows are disabled after 60 days without repository activity.

Manual runs with workflow_dispatch

workflow_dispatch adds a Run workflow button to the Actions tab — but only once the file is on the default branch. It can also be started with gh workflow run or the REST API, against any branch or tag.

name: Deploy

on:
  workflow_dispatch:
    inputs:
      target:
        description: Where to deploy
        type: environment          # a dropdown of the repository's environments
        required: true
      version:
        description: Release tag, e.g. v2.4.0
        type: string
        required: true
      replicas:
        type: number
        default: 2
      dry-run:
        type: boolean
        default: true
      region:
        type: choice
        options: [eu-west, us-east, ap-south]
        default: eu-west

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.target }}
    steps:
      - name: Show the request
        env:
          VERSION: ${{ inputs.version }}
          DRY_RUN: ${{ inputs.dry-run }}
        run: echo "Deploying $VERSION, dry run $DRY_RUN"

Reusable workflows with workflow_call

A workflow with on: workflow_call is called as a job, with jobs.<id>.uses. The called workflow declares its inputs (types boolean, number or string — no choice), its secrets and its outputs; the caller maps values into them.

name: Reusable build

on:
  workflow_call:
    inputs:
      node-version:
        type: string               # boolean, number or string only
        default: '24'
      run-e2e:
        type: boolean
        default: false
    secrets:
      npm_token:
        required: true
    outputs:
      image-tag:
        description: Tag of the image that was built
        value: ${{ jobs.build.outputs.tag }}

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      tag: ${{ steps.meta.outputs.tag }}
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.npm_token }}
      - id: meta
        run: echo "tag=sha-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"

name: CI

on:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  build:
    uses: octo-org/platform/.github/workflows/build.yml@v3
    with:
      node-version: '24'
      run-e2e: true
    secrets:
      npm_token: ${{ secrets.NPM_TOKEN }}   # or: secrets: inherit

  report:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Built ${{ needs.build.outputs.image-tag }}"

• Reference a reusable workflow as owner/repo/.github/workflows/file.yml@ref, or ./.github/workflows/file.yml in the same repository (same commit, no @ref).
• Secrets are not passed implicitly. Map each one under secrets:, or pass secrets: inherit to hand over every secret the caller can see (same organisation or enterprise only).
• The caller's env context is not propagated; use inputs.
• A calling job can only use with, secrets, needs, if, permissions, concurrency and strategy — no steps and no runs-on.
• The called workflow can keep or reduce the GITHUB_TOKEN permissions it receives, never raise them.
• Up to ten levels of nesting, and at most 50 unique reusable workflows from one workflow file (both raised in November 2025 from four and 20).

External events with repository_dispatch

Another system starts a workflow by calling the REST API with an event_type (up to 100 characters) and an optional client_payload (up to 10 top-level properties). The workflow must be on the default branch.

gh api repos/octo-org/web/dispatches \
  -f event_type=deploy-requested \
  -F 'client_payload[env]=staging' \
  -F 'client_payload[sha]=1f2e3d4'

on:
  repository_dispatch:
    types: [deploy-requested]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - env:
          TARGET: ${{ github.event.client_payload.env }}
        run: echo "Deploying to $TARGET"

Choose scope, permissions and events

Design and implement workflow structure

Jobs, steps and conditional logic

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    defaults:
      run:
        shell: bash
        working-directory: app
    steps:
      - uses: actions/checkout@v7
      - id: unit
        run: npm test
        continue-on-error: true          # the step "fails" but the job carries on

      - name: Only on main pushes
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: ./scripts/publish-preview.sh

      - name: Tell us when unit tests failed
        if: steps.unit.outcome == 'failure'   # outcome: before continue-on-error
        run: echo "::warning::Unit tests failed"

      - name: Always clean up
        if: always()
        run: ./scripts/cleanup.sh

      - name: Only when an earlier step failed
        if: failure()
        run: ./scripts/collect-diagnostics.sh

• An if: without a status function gets success() && prepended — so if: github.ref == 'refs/heads/main' does not run after a failure.
• ${{ }} is optional in if:, except when the expression starts with ! — YAML would read that as a tag, so write if: ${{ !cancelled() }}.
• steps.<id>.outcome is the result before continue-on-error; conclusion is after it. A failed step with continue-on-error: true has outcome failure, conclusion success.
• timeout-minutes defaults to 360 for a job; set it lower to stop hung jobs burning minutes. Steps take it too.
• defaults.run sets shell and working-directory for run steps at workflow or job level — not for uses steps.

Dependencies between jobs

flowchart LR
  LINT["lint"]:::success --> BUILD["build"]:::success
  TEST["test"]:::failure --> DEPLOY["deploy<br/>needs: build, test"]:::skipped
  BUILD --> DEPLOY
  DEPLOY --> NOTIFY["notify<br/>if: always()"]:::success

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [{ run: npm run lint }]
  build:
    needs: lint
    runs-on: ubuntu-latest
    steps: [{ run: npm run build }]
  test:
    runs-on: ubuntu-latest
    steps: [{ run: npm test }]
  deploy:
    needs: [build, test]               # skipped if either does not succeed
    runs-on: ubuntu-latest
    steps: [{ run: ./deploy.sh }]
  notify:
    needs: deploy
    if: ${{ always() }}                 # runs even though deploy was skipped
    runs-on: ubuntu-latest
    steps:
      - run: echo "deploy result was ${{ needs.deploy.result }}"

A job runs only when every job in its needs succeeded, unless its if: uses a status function. A skipped job counts as not-succeeded for its dependants, so skips propagate down the chain. needs.<job>.result is success, failure, cancelled or skipped.

Workflow commands and environment variables

Variables set with env: at workflow, job or step level are visible to steps; the most specific wins (step over job over workflow). The runner also sets default variables — GITHUB_SHA, GITHUB_REF, GITHUB_REPOSITORY, GITHUB_WORKSPACE, RUNNER_OS, RUNNER_TEMP and more — which you cannot overwrite (names starting GITHUB_ are reserved). The full list is in the Syntax reference.

Steps talk to the runner in two ways: environment files, written with >>, and workflow commands, printed to standard output as ::command parameters::value.

steps:
  - name: Set values for later steps
    run: |
      echo "BUILD_ID=$(date +%s)" >> "$GITHUB_ENV"       # env var for later steps
      echo "$HOME/.local/bin" >> "$GITHUB_PATH"            # prepend to PATH
      {
        echo 'NOTES<<EOF'                                  # multiline value
        git log -3 --oneline
        echo 'EOF'
      } >> "$GITHUB_ENV"

  - name: Use them
    run: |
      echo "Build $BUILD_ID"
      echo "$NOTES"

echo "::group::Install dependencies"
npm ci
echo "::endgroup::"

echo "::error file=src/checkout.ts,line=42,col=7::Expected total to be 30, received 3"
echo "::warning::Coverage dropped below 80% (78.4%)"
echo "::notice title=Preview::Deployed to $PREVIEW_URL"

TOKEN=$(./scripts/fetch-token.sh)
echo "::add-mask::$TOKEN"          # mask a value that is not a secret
echo "::debug::only shown when step debug logging is on"

And what those commands look like in the job log:

Service containers

services: starts Docker containers — databases, caches, queues — alongside a job, and tears them down when it ends. They need a Linux runner (GitHub-hosted Ubuntu, or a self-hosted Linux runner with Docker). How you reach them depends on where the job runs:

jobs:
  integration:
    runs-on: ubuntu-latest           # service containers need a Linux runner
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_PASSWORD: postgres
        ports:
          - 5432:5432                # host:container — needed when the job is on the runner
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis:8
        ports:
          - 6379:6379
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm run test:integration
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/postgres
          REDIS_URL: redis://localhost:6379

jobs:
  integration:
    runs-on: ubuntu-latest
    container: node:24               # the job itself runs in a container…
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_PASSWORD: postgres
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm run test:integration
        env:
          # …so services are reached by their label on the job's network
          DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres

options: passes Docker create flags; health checks (--health-cmd, --health-interval, --health-retries) make the runner wait until the service is healthy before the first step. credentials: pulls from a private registry, and the mapped host port is available as ${{ job.services.postgres.ports[5432] }} when you map to a random port.

Strategy and matrix

jobs:
  test:
    name: test (${{ matrix.os }}, node ${{ matrix.node }})
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false               # default true: one failure cancels the rest
      max-parallel: 4
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [22, 24]
        exclude:
          - os: macos-latest
            node: 22                   # drop one combination
        include:
          - os: ubuntu-latest
            node: 26
            experimental: true         # add a combination with an extra key
          - os: windows-latest
            node: 24
            npm-flags: --no-audit      # add a key to an existing combination
    continue-on-error: ${{ matrix.experimental == true }}
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci ${{ matrix.npm-flags }}
      - run: npm test

flowchart LR
  A["test (ubuntu-latest, node 22)"]:::success --> P["publish<br/>needs: test"]:::skipped
  B["test (windows-latest, node 24)"]:::failure --> P
  C["test (macos-latest, node 24)"]:::success --> P
  D["test (ubuntu-latest, node 26)"]:::success --> P

• The matrix is the cartesian product of its axes; exclude is applied first, then include.
• include adds keys to every existing combination it fully matches without overwriting an original value; if it matches none, it adds a new combination.
• A matrix can generate up to 256 jobs per workflow run.
• fail-fast (default true) cancels in-progress and queued legs when one fails; max-parallel caps how many run at once.
• continue-on-error at job level lets an experimental leg fail without failing the run.
• A matrix can be built at runtime: output JSON from an earlier job and use ${{ fromJSON(needs.plan.outputs.matrix) }}.

YAML anchors and aliases

Since September 2025 workflows accept YAML anchors (&name, which labels a value) and aliases (*name, which repeats it) to reuse a mapping, a sequence or a whole step within one file. Anchors do not cross files — reuse across files is what reusable workflows and composite actions are for.

jobs:
  test:
    runs-on: ubuntu-latest
    env: &shared-env                 # anchor: name this mapping
      NODE_ENV: test
      TZ: UTC
    steps:
      - &checkout                    # anchor a whole step
        uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - run: npm test

  lint:
    runs-on: ubuntu-latest
    env: *shared-env                 # alias: the same mapping again
    steps:
      - *checkout                    # the same step again
      - run: npm run lint

The study guide also lists the YAML merge key, <<, which copies every key of an aliased mapping into the current one and lets local keys override:

# YAML merge keys: valid YAML 1.1, not documented for GitHub Actions
base: &base
  runs-on: ubuntu-latest
  timeout-minutes: 10

lint:
  <<: *base                # copy every key of the base mapping…
  timeout-minutes: 5       # …then override one (local keys win)

Predefined contexts

github.ref is the full ref (refs/heads/main, refs/tags/v1.2.0, refs/pull/42/merge); github.ref_name is the short name. In a pull_request run, github.head_ref and github.base_ref hold the branch names, and github.sha is the merge commit, not the head of the branch.

Expressions

- name: Expressions, one per variable
  if: ${{ github.event_name == 'pull_request' && !github.event.pull_request.draft }}
  env:
    # Literals: numbers, booleans, null, and single-quoted strings ('' escapes ')
    ANSWER: ${{ 42 }}
    QUOTE: ${{ 'it''s' }}
    # Operators
    RELEASE: ${{ github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/') }}
    # Functions — the object filter * collects a property from every item
    WANTS_DEPLOY: ${{ contains(github.event.pull_request.labels.*.name, 'deploy') }}
    CACHE_KEY: ${{ format('{0}-{1}', runner.os, hashFiles('**/package-lock.json')) }}
    TARGETS: ${{ join(github.event.pull_request.labels.*.name, ', ') }}
    COMMIT_JSON: ${{ toJSON(github.event.pull_request.head) }}
    # A "ternary": cond && a || b — b wins whenever a is falsy
    STAGE: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}
  run: echo "$STAGE $CACHE_KEY"

• Comparisons are loose: strings compare case-insensitively, and mismatched types are coerced to numbers ('' == 0 and null == 0 are true).
• Falsy values are false, 0, -0, '' and null; everything else, including 'false', is truthy.
• hashFiles() returns one SHA-256 for every file matching the patterns, relative to GITHUB_WORKSPACE — empty if nothing matches.
• fromJSON() turns a JSON string — typically a job output — back into an object, array, number or boolean, which is how a matrix is built at runtime.
• Expressions are not allowed in on: or in uses:.

Static and runtime evaluation

Two things are easy to blur. When an expression is evaluated depends on its key: workflow-level keys when the run is queued, job-level keys when the job is scheduled, step keys just before the step — which is why a job's if: cannot see steps and runs-on cannot use env. How it reaches a script matters too: a ${{ }} inside run: is substituted into the script text before the shell starts, while $VAR is read by the shell at runtime. The first lets attacker-controlled text become code; the second keeps it data.

steps:
  - name: Wrong — secret pasted into the script, and leaked by a transform
    run: |
      curl -H "Authorization: Bearer ${{ secrets.API_TOKEN }}" https://api.example.com
      echo "${{ secrets.API_TOKEN }}" | base64      # the base64 form is NOT masked

  - name: Right — secret passed as an environment variable
    env:
      API_TOKEN: ${{ secrets.API_TOKEN }}
    run: |
      curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com

  - name: Gate on a secret being present (secrets cannot be used in if:)
    if: env.HAS_TOKEN == 'true'
    env:
      HAS_TOKEN: ${{ secrets.API_TOKEN != '' }}
    run: ./scripts/publish.sh

• Secrets are masked in logs as *** — but only their exact value. Anything derived from a secret (base64, a JSON field, a substring) is not masked unless you register it with ::add-mask::.
• Pass secrets through env: or with:, not on a command line, where they can show up in process lists.
• Do not store structured data (JSON, YAML) as a single secret: masking works on exact strings.
• The secrets context cannot be referenced directly in if:; map it to an env value first, as in the last step above.

Editor tooling

The GitHub Actions extension for VS Code (github.vscode-github-actions) understands workflow files: syntax highlighting, IntelliSense for keys, contexts and expressions, action metadata completion (it reads the inputs of the action you uses:), validation errors as you type, and a panel to browse workflows and runs, read logs, re-run jobs and trigger workflow_dispatch runs without leaving the editor.

• YAML schema completion: any editor with a YAML language server picks up the SchemaStore schemas for workflows and action.yml, giving key completion and type checking.
• actionlint is an open-source linter that catches what schemas cannot: unknown contexts, type errors in expressions, invalid needs, shell issues and injection-prone run: lines. Run it locally and in CI.
• The workflow editor on GitHub.com offers the same completion and a Marketplace side panel for searching actions.

Manage workflow execution and outputs

Caching dependencies

steps:
  - uses: actions/checkout@v7
  - uses: actions/cache@v6
    id: cache
    with:
      path: ~/.npm
      key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        npm-${{ runner.os }}-
  - if: steps.cache.outputs.cache-hit != 'true'
    run: echo "No exact match — restored from a prefix, or nothing"
  - run: npm ci

  # Or let the setup action do it:
  - uses: actions/setup-node@v7
    with:
      node-version: 24
      cache: npm                       # keys on the lockfile automatically

• Lookup order: exact key, then each restore-keys prefix in order, newest match first. cache-hit is 'true' only for an exact key match.
• A cache is immutable: an existing key is never overwritten. Change the key (usually via hashFiles) to save a new one.
• Scope: a run can restore caches from its own branch or the default branch; a pull request also from its base branch. Sibling branches never share.
• Caches not accessed for 7 days are evicted; the repository limit is 10 GB by default (admins can raise it, billed beyond), oldest-accessed evicted first.
• The setup-* actions have built-in caching (cache: npm, pip, gradle…), keyed on the lockfile.

Artifacts

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: web-dist
          path: |
            dist/
            !dist/**/*.map
          retention-days: 5            # within the repository's maximum
          if-no-files-found: error

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v8
        with:
          name: web-dist
          path: dist

• upload-artifact@v7 and download-artifact@v8 are the current majors. Since v4, artifacts are immutable and an artifact name must be unique in a run — upload once per name, or pass overwrite: true.
• For a matrix, give each leg its own name (coverage-${{ matrix.os }}) and download with pattern: coverage-* and merge-multiple: true.
• v7 can upload a single file unzipped with archive: false; v8 checks digests and fails on a mismatch by default.
• Default retention is 90 days. Public repositories allow 1–90 days; private and internal up to 400. retention-days can shorten, never exceed, the configured maximum.

Retention policies via the REST API

The artifact and log retention setting covers artifacts, logs and workflow-run data. Set it in Settings → Actions → General, or programmatically — at enterprise, organisation or repository level, where each level can only be the same or shorter than the one above.

# Read, then set, the default retention (days) for artifacts and logs
gh api repos/octo-org/web/actions/permissions/artifact-and-log-retention
gh api -X PUT repos/octo-org/web/actions/permissions/artifact-and-log-retention -F days=30

# The same at organisation level (repositories cannot exceed it)
gh api -X PUT orgs/octo-org/actions/permissions/artifact-and-log-retention -F days=60

# Clean up ahead of retention: one artifact, one run's logs, one whole run
gh api -X DELETE repos/octo-org/web/actions/artifacts/1234567
gh api -X DELETE repos/octo-org/web/actions/runs/987654321/logs
gh api -X DELETE repos/octo-org/web/actions/runs/987654321

There is no separate "keep runs for N days" switch: runs age out with the retention period, and you can delete a run, its logs or an artifact early through the API, the UI or gh run delete.

Passing data between jobs and steps

flowchart LR
  subgraph J1["Job: plan"]
    direction TB
    S1["Step writes<br/>GITHUB_OUTPUT"] --> S2["steps.id.outputs"]
  end
  S2 --> JO["jobs.plan.outputs"]
  JO --> N["needs.plan.outputs<br/>in later jobs"]
  N --> WO["on.workflow_call.outputs<br/>back to a caller"]

jobs:
  plan:
    runs-on: ubuntu-latest
    outputs:                                     # 2 · publish as job outputs
      version: ${{ steps.ver.outputs.version }}
      targets: ${{ steps.ver.outputs.targets }}
    steps:
      - id: ver                                  # 1 · a step writes outputs
        run: |
          echo "version=2.4.0" >> "$GITHUB_OUTPUT"
          echo 'targets=["eu","us"]' >> "$GITHUB_OUTPUT"

  release:
    needs: plan                                  # 3 · read them through needs
    runs-on: ubuntu-latest
    strategy:
      matrix:
        region: ${{ fromJSON(needs.plan.outputs.targets) }}
    steps:
      - run: echo "Releasing ${{ needs.plan.outputs.version }} to ${{ matrix.region }}"

Job summaries

Markdown appended to $GITHUB_STEP_SUMMARY is rendered on the run's summary page, under the job — tables, links, emoji, collapsed sections and all. Each step has its own file, limited to 1 MiB, and up to 20 step summaries are shown per job. Secrets are masked there too.

- name: Publish a job summary
  if: always()
  run: |
    {
      echo "## Test results :white_check_mark:"
      echo ""
      echo "| Suite | Passed | Failed |"
      echo "| ----- | -----: | -----: |"
      echo "| unit  | 412    | 0      |"
      echo "| e2e   | 37     | 1      |"
      echo ""
      echo "Coverage: **84.1%** · [Full report]($REPORT_URL)"
    } >> "$GITHUB_STEP_SUMMARY"

Status badges

A badge shows the status of the latest run of a workflow, by default for the default branch. Copy it from the workflow's ⋯ → Create status badge menu, or build the URL from the workflow file name; branch and event query parameters narrow it.

![CI](https://github.com/octo-org/web/actions/workflows/ci.yml/badge.svg)
![CI on main](https://github.com/octo-org/web/actions/workflows/ci.yml/badge.svg?branch=main)
![CI for pushes](https://github.com/octo-org/web/actions/workflows/ci.yml/badge.svg?event=push)

Environment protections

An environment is a deployment target with its own secrets, variables and protection rules. A job that names it waits at the start until every rule passes, then gets the environment's secrets.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: ${{ steps.deploy.outputs.url }}   # shown on the run graph and in Deployments
    concurrency:
      group: production
      queue: max                             # deployments wait in line, none are dropped
    steps:
      - id: deploy
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}   # an environment secret
          API_URL: ${{ vars.API_URL }}           # an environment variable
        run: ./deploy.sh

• Referencing an environment that does not exist creates it, with no protection rules.
• A job waits at most 30 days for approval before it fails.
• Since December 2025, branch rules match the executing ref for pull request events: refs/pull/<n>/merge for pull_request, the default branch for pull_request_target.
• Plans: environments, their secrets and branch rules are available for public repositories on every plan, and for private ones on Pro, Team and Enterprise; required reviewers and wait timers in private repositories need Enterprise.