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 lnurl_transfer grep is @lnurl|@transfer_2. Staging shards stay @multi_address_2, @pubky, @hardware_wallet, @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.

Design

N/A — no UI changes.

Preview

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.

[github-actions]

Regtest APK

Built from 52a432b (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[greptile-apps]

Confidence Score: 4/5

The workflow changes appear functionally safe to merge, with a non-blocking supply-chain hardening issue in the Slack summary jobs.

Findings

1.   Mutable Code Receives Secret ▶

Summary

This PR makes local E2E tests the pull-request merge gate, reallocates transfer scenarios between local and staging workflows, and adds release-branch migration runs with optional Slack reporting.

• Removes staging build and test jobs from the PR workflow and simplifies e2e-status to require local shards only.
• Adds @transfer_1 to scheduled/manual staging coverage while limiting the local transfer shard to @transfer_2.
• Runs migration jobs for non-draft pull requests whose source or target branch begins with release-.
• Adds migration Slack summaries for scheduled runs and opted-in manual dispatches.
• The new reporting path should use immutable references before executing external code with the Slack webhook.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  PR[Pull request] --> LOCAL[Local E2E shards]
  LOCAL --> GATE[e2e-status merge gate]

  SCHED[Schedule] --> STAGING[Staging E2E shards]
  DISPATCH[Manual dispatch] --> STAGING
  STAGING --> STAGING_REPORT[Staging Slack summary]

  RELEASE_PR[Non-draft release-* PR] --> MIGRATION[Migration E2E matrix]
  SCHED --> MIGRATION
  DISPATCH --> MIGRATION
  MIGRATION --> CHECK{Schedule or opted-in dispatch?}
  CHECK -->|Yes| MIGRATION_REPORT[Migration Slack summary]
  CHECK -->|No| DONE[Finish without Slack post]

Loading

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

[greptile-apps]

Mutable Code Receives Secret

The new migration report checks out actions/checkout@v7 and synonymdev/bitkit-e2e-tests@main through mutable references, then runs the downloaded scripts/slack_summary.py with the staging Slack webhook in its environment. If either reference is repointed or compromised, scheduled and opted-in dispatch runs can execute substituted code, expose the webhook, or post unauthorized messages. Pin both executable dependencies to immutable commit SHAs. The staging report has the same exposure at .github/workflows/e2e-staging.yml:246-249.

How this was verified: The checked-out external Python script is executed immediately afterward with SLACK_WEBHOOK_URL_STAGING supplied as SLACK_WEBHOOK_URL.

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!