ci: make local e2e the merge gate

[piotr-iohk]

Related to synonymdev/bitkit-e2e-tests#221 (PR B)

This PR:

1. Drops staging jobs from the local merge-gate workflow so required e2e-status is local-only
2. Keeps e2e-staging.yml on schedule and dispatch (no PR trigger)
3. Runs migration on release-* PRs and posts the same Slack summary as staging

Description

Staging stays off the merge gate. Feature PRs no longer wait on stag0. Local grep is @transfer_2 instead of blob @transfer. Staging shards stay @multi_address_2, @pubky, @transfer_max (@transfer_1 later). Slack checkout uses the resolved e2e-tests branch so a same-named branch can test slack_summary.py.

Migration: pull_request runs only when head or base starts with release-. Slack posts on schedule and on dispatch when post_to_slack is true, using SLACK_WEBHOOK_URL_STAGING.

Linked Issues/Tasks

synonymdev/bitkit-e2e-tests#221

Design

N/A — no UI changes.

Screenshot / Video

N/A

QA Notes

Manual Tests

N/A

Automated Checks

• Workflow YAML only. After merge: a feature PR should go green on e2e-status without staging jobs.
• After merge: gh workflow run e2e-staging.yml still works; migration on a release-* PR should run; nightly/dispatch with post_to_slack posts to #bitkit-staging-nightly.

[greptile-apps]

Confidence Score: 4/5

The workflow changes appear safe to merge, with one non-blocking supply-chain hardening concern in the migration Slack report.

Findings

1.   Mutable Script Receives Secret ▶

Summary

This PR makes local E2E tests the sole merge gate and separates staging and migration coverage from ordinary feature PRs.

• Removes staging build and test jobs from the required e2e-status dependency graph.
• Splits transfer coverage between local @transfer_2 and staging @transfer_1|@transfer_max runs.
• Adds migration execution for non-draft release-head or release-target PRs.
• Adds scheduled and opt-in migration Slack reporting.
• Standardizes Slack summary scripts on the E2E repository's main branch.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  PR[Pull request] --> Local[Local E2E shards]
  Local --> Gate[e2e-status merge gate]
  PR --> Release{Head or base starts release-?}
  Release -->|Yes| Migration[Migration matrix]
  Release -->|No| Skip[Migration jobs skipped]
  Schedule[Schedule] --> Staging[Staging E2E shards]
  Schedule --> Migration
  Dispatch[Manual dispatch] --> Staging
  Dispatch --> Migration
  Staging --> StagingSlack[Staging Slack summary]
  Migration --> MigrationSlack[Migration Slack summary]

Loading

_{Reviews (1) · Last reviewed commit: "ci: make local e2e the merge gate"}

[greptile-apps]

Mutable Script Receives Secret

The Slack report checks out scripts/slack_summary.py from the mutable bitkit-e2e-tests@main branch and then runs it with SLACK_WEBHOOK_URL_STAGING in its environment. A later change or compromise of that branch could access the webhook without a reviewed change in this repository. Pin the external repository to a reviewed commit SHA.

How this was verified: The checked-out remote script runs directly in the following step with the Slack webhook present in its process environment.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!