ci: add e2e-staging workflow for nightly staging tests

[piotr-iohk]

Fixes synonymdev/bitkit-e2e-tests#221 (PR A — android)

Description

Adds a new workflow .github/workflows/e2e-staging.yml that runs staging E2E tests:

• Triggers:

  • schedule: runs daily at 04:00 UTC (after migration cron at 02:00)
  • workflow_dispatch: manual dispatch with e2e_branch input (same shape as existing e2e.yml)
  • pull_request: self-tests on this PR

• Staging shards (moved from e2e.yml):

  • @multi_address_2
  • @pubky
  • @hardware_wallet
  • @transfer_1|@transfer_max (new per issue — HW full path / channel assert stays on staging)

• Build: Uses BACKEND=regtest with TREZOR_BRIDGE: true matching existing staging build config

• Slack: Notifies #bitkit-staging-nightly via secrets.SLACK_WEBHOOK_URL_STAGING on failure (only for scheduled/manual runs, not PRs)

The existing e2e.yml workflow remains unchanged — the e2e-status merge gate is unaffected.

Design

N/A — no UI changes.

Preview

N/A

QA Notes

To dispatch after merge:

gh workflow run e2e-staging.yml -f e2e_branch=main

The workflow will also run automatically on this PR to self-test, and nightly at 04:00 UTC after merge.

  

[github-actions]

Regtest APK

Built from 70c607d (run).

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

[greptile-apps]

Confidence Score: 4/5

The workflow should not merge until scheduled and manual build or branch-selection failures reliably trigger the promised Slack notification.

Findings

1.  Upstream Failures Skip Alerts ▶
2.  Pull Requests Duplicate Shards ▶

Summary

• Builds a network-backed regtest APK with Trezor Bridge support.
• Runs multi-address, Pubky, hardware-wallet, and transfer shards with retries.
• Uploads failure artifacts and attempts to notify the staging Slack channel.
• The failure notification currently misses upstream failures, and the pull-request trigger duplicates existing staging shards on future PRs.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Trigger[Schedule / Manual / Pull Request] --> Build[build-staging]
  Trigger --> Branch[e2e-branch]
  Build --> Tests[e2e-tests-staging matrix]
  Branch --> Tests
  Tests -->|failure| Notify[notify-failure]
  Build -. failure skips tests .-> Missed[No Slack notification]
  Branch -. failure skips tests .-> Missed

Loading

_{Reviews (1) · Last reviewed commit: "ci: add e2e-staging workflow for nightly..."}

[greptile-apps]

Upstream Failures Skip Alerts

The notification job only observes e2e-tests-staging. If build-staging or e2e-branch fails during a scheduled or manual run, the test job is skipped and its result is skipped, so no Slack notification is sent. Include the upstream jobs in needs and alert when any required job is unsuccessful.

Suggested change

	if: always() && github.event_name != 'pull_request' && needs.e2e-tests-staging.result == 'failure'
	needs: [e2e-tests-staging]
	if: always() && github.event_name != 'pull_request' && (needs.build-staging.result != 'success' || needs.e2e-branch.result != 'success' || needs.e2e-tests-staging.result != 'success')
	needs: [build-staging, e2e-branch, e2e-tests-staging]

[greptile-apps]

Pull Requests Duplicate Shards

This unrestricted trigger runs the new workflow on every future pull request. Because e2e.yml still runs the same multi-address, Pubky, and hardware-wallet shards, each PR will launch those expensive emulator jobs twice. Remove or explicitly scope this trigger if it was only intended to self-test this PR.

Suggested change

	pull_request:
	types: [opened, synchronize, reopened, ready_for_review]

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!