Automate Taskcluster reports and optional Pages publishing with GitHub Actions

[aerickson]

Add GitHub Actions workflows to replace the NAS-based report automation, with optional GitHub Pages publishing.

The report workflow snapshots configuration, creates worker probes, waits 90 minutes, collects results, commits snapshots, and rebuilds history. Manual runs default to dry-run mode: they create real probes and upload a reviewable patch, but do not push or deploy.

Scheduled runs are opt-in and run every Monday at 07:23 UTC (12:23 a.m. PDT / Sunday 11:23 p.m. PST). GitHub may delay scheduled starts.

Setup and rollout

1. Merge the workflows into the default branch.
2. Create a dedicated Taskcluster client with the scopes below, and configure repository Actions secrets TASKCLUSTER_CLIENT_ID and TASKCLUSTER_ACCESS_TOKEN.
3. Ensure branch rules allow the Actions bot to push report commits to the default branch using GITHUB_TOKEN.
4. Disable the NAS job before testing to avoid duplicate probes.
5. Manually run Mozilla history reports with dry_run=true. Verify that the restricted client works, and review the task group, logs, and report-changes patch artifact.
6. Run again from the default branch with dry_run=false and verify the published reports and history. This creates another set of probes.
7. Set repository Actions variable ENABLE_SCHEDULED_REPORTS=true to enable weekly runs, and retire the NAS job after successful verification.

Maintainers should enable Actions failure notifications. Remove or disable ENABLE_SCHEDULED_REPORTS to stop scheduled scans; manual runs remain available.

Taskcluster client scopes

Proposed explicit scopes for the dedicated automation client:

• auth:list-clients
• queue:create-task:lowest:*
• queue:scheduler-id:smoketest
• queue:seal-task-group:smoketest/*

These allow client enumeration, lowest-priority probes across the discovered worker pools, and task-group sealing under scheduler smoketest. Other required read permissions are currently provided by Firefox CI's anonymous role. The tools do not require worker-quarantine or secret-reading permissions.

This scope set was derived from the reporting code and live API definitions; validate it with the initial manual dry run before enabling scheduling.

Runtime and cost

Each report run includes a 90-minute wait for worker probes and has a 150-minute timeout. Scheduling is weekly and opt-in, with report runs serialized to prevent overlap.

The workflow uses standard GitHub-hosted Ubuntu runners, which are free for public repositories under GitHub's current billing policy.

Optional GitHub Pages publishing

• Set Settings → Pages → Build and deployment → Source to GitHub Actions.
• Run Publish report to GitHub Pages manually to verify deployment; this does not create probes or require Taskcluster credentials.
• Set repository Actions variable PUBLISH_REPORT_PAGES=true to deploy automatically after successful non-dry report runs. Leave unset to retain the existing publishing setup.

Validation

Rebased onto the merged reporting improvements without conflicts or changes to either commit. Zizmor passes; local actionlint flags the $/ reusable-workflow syntax recommended by zizmor. End-to-end report generation and deployment have not been run.

[lotas]

let's see how it works, thanks!