ci(e2e): bind behaviour job to dev and stage environments

[ifireball]

Summary

• Bind the behaviour job to GitHub Environments dev (authorized PRs and merge queue) and stage (push to main); skip workflow_dispatch and other triggers.
• Expose a matching ENVIRONMENT env var to the suite (dev/stage, local default dev) so later STAGE-infra work does not have to guess the trigger.
• Job listing in Environments uses the default deployment: true from the scalar environment: key; the job token is not granted deployments: write.

Part of the work for #5115. This PR does not close that issue.

Test plan

• Confirm a PR run of the behaviour job appears under the dev environment and has ENVIRONMENT=dev.
• Confirm a push-to-main run appears under stage and has ENVIRONMENT=stage.
• Confirm workflow_dispatch of E2E Tests skips the behaviour job (admin e2e job still runs).
• Confirm merge-queue still gets a behaviour check (required) bound to dev.
• go test ./pkg/behaviourtest/drivers/env/ passes locally.

[qodo-code-review]

PR Summary by Qodo

Bind behaviour E2E runs to dev and stage environments

⚙️ Configuration changes ✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Routes authorized PR and merge-queue behaviour runs to dev; main pushes to stage.
• Exposes and validates matching ENVIRONMENT values, defaulting local runs to dev.
• Documents CI environment behavior and operational stage restrictions.

Diagram

graph TD
  A["Workflow event"] --> B{"Eligible trigger?"} -->|Authorized PR or merge queue| D["dev environment"] --> C["Behaviour job"] --> F["Runner config"] --> G["Behaviour suite"]
  B -->|Main push| E["stage environment"] --> C
  B -->|Other trigger| H["Job skipped"]

Loading

High-Level Assessment

The current approach is appropriate: one behaviour job preserves the existing required check while dynamically selecting its GitHub Environment and matching suite variable. Separate dev/stage jobs would duplicate workflow steps, while computing the mapping through another job output would add indirection without improving the two-value event mapping.

Files changed (6) +98 / -2

Enhancement (1) +9 / -0

env.goLoad and validate the suite environment target +9/-0

Load and validate the suite environment target

• Extends 'RunnerConfig' with an 'Environment' field loaded from 'ENVIRONMENT', defaulting empty values to 'dev'. Validation now accepts only 'dev' and 'stage'.

pkg/behaviourtest/drivers/env/env.go

Tests (1) +66 / -0

env_test.goTest environment loading and validation +66/-0

Test environment loading and validation

• Covers the default, explicit stage value, whitespace trimming, accepted targets, and rejection of unknown or empty manually constructed values.

pkg/behaviourtest/drivers/env/env_test.go

Documentation (3) +9 / -1

behaviour-drivers.mdDocument behaviour runner environment selection +2/-1

Document behaviour runner environment selection

• Adds 'ENVIRONMENT' to the runner configuration reference and documents its accepted values, local default, and startup validation.

docs/guides/dev/behaviour-drivers.md

behaviour-testing.mdExplain local and CI environment defaults +3/-0

Explain local and CI environment defaults

• Documents how local, pull request, merge queue, and main-branch runs select 'dev' or 'stage'.

docs/guides/dev/behaviour-testing.md

e2e-testing.mdDocument behaviour job GitHub Environments +4/-0

Document behaviour job GitHub Environments

• Describes the workflow-to-environment mapping, skipped triggers, automatic environment creation, and the required main-branch restriction for 'stage'.

docs/guides/dev/e2e-testing.md

Other (1) +14 / -1

e2e.ymlRoute behaviour runs to event-specific GitHub Environments +14/-1

Route behaviour runs to event-specific GitHub Environments

• Restricts the behaviour job to authorized pull requests, merge queue runs, and pushes to main. Binds those runs to 'dev' or 'stage' and exports the matching 'ENVIRONMENT' value to the test suite.

.github/workflows/e2e.yml

[github-actions]

Site preview

Preview: https://9270017b-site.fullsend-ai.workers.dev

Commit: f9d81641f43090c41cc5b3605499a235430a00fd

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:00 AM UTC · Completed 8:13 AM UTC

Commit: e7974e0 · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. stage restriction uses prose ✓ Resolved 📜 Skill insight ✧ Quality

Description

The operator instruction to restrict stage to main is embedded in a prose paragraph instead of
an ordered list. This makes the new procedural step violate the required guide format.

Code

docs/guides/dev/e2e-testing.md[73]

+The behaviour job in `e2e.yml` binds to GitHub Environments `dev` (authorized pull requests and the merge queue) and `stage` (push to `main`). It skips `workflow_dispatch` and other triggers. GitHub auto-creates those environments on first use. Restrict `stage` to the `main` branch once they exist (operator step). The job sets `ENVIRONMENT` to the same value for the suite (`dev` or `stage`).

Relevance

●●● Strong

Recent e2e-guide precedent accepted converting procedural prose to numbered steps; this finding
directly enforces that format.

PR-#2277
PR-#5546

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 1062079 requires all procedural guide content to use numbered lists. The added text explicitly
labels Restrict stage to the main branch as an operator step but presents it inside an unnumbered
paragraph.

docs/guides/dev/e2e-testing.md[71-73]
Skill: writing-user-docs

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new instruction to restrict the `stage` GitHub Environment to `main` is procedural content written inline as prose.

## Issue Context
PR Compliance ID 1062079 requires procedural content in documentation guides to use numbered steps.

## Fix Focus Areas
- docs/guides/dev/e2e-testing.md[71-73]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 56 rules

✅ Skills: writing-user-docs, writing-adrs

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Review

Findings

High

• [protected-path] .github/workflows/e2e.yml — This PR modifies .github/workflows/e2e.yml, which is under the .github/ protected path. The PR has no linked issue providing explicit authorization for changes to governance and infrastructure files. Human approval is required for all protected-path changes.
  Remediation: Link the authorizing issue in the PR description, or obtain human reviewer approval for the .github/ changes.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run

Review

Findings

High

• [protected-path] .github/workflows/e2e.yml — This PR modifies .github/workflows/e2e.yml, which is under the .github/ protected path. The PR has no linked issue providing explicit authorization for changes to governance and infrastructure files. Human approval is required for all protected-path changes.
  Remediation: Link the authorizing issue in the PR description, or obtain human reviewer approval for the .github/ changes.

Low

• [redundancy] .github/workflows/e2e.yml:275 — ENVIRONMENT is set both as a job-level env var (line 205) and again in the "Run behaviour tests" step env block (line 275) with the identical expression ${{ github.event_name == 'push' && 'stage' || 'dev' }}. The step-level entry is redundant since the job-level env already provides it to all steps.
  Remediation: Remove the ENVIRONMENT entry from the step-level env block on the "Run behaviour tests" step, since the job-level env already provides it to all steps.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

[ifireball]

/fs-fix

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:56 AM UTC · Completed 10:09 AM UTC

Commit: f9d8164 · View workflow run →

[fullsend-ai-review]

See the review comment for full details.

[waynesun09]

LGTM. Validated at head f9d8164: the behaviour-job if correctly restricts to push-to-main / merge_group / authorized PRs, environment keys off event_name (right call for pull_request_target), ENVIRONMENT is set once at job level and validated in RunnerConfig.Validate with tests. Earlier bot findings (redundant step env, prose procedure) are addressed; CI green. The remaining fullsend-ai-review protected-path finding is satisfied by human approval.