GitHub Actions on g1t, part two: running workflows
A repository's .github/workflows run on g1t as they are. The new g1t-actions service reads them at the commit an event is about, matches their triggers and filters (push, pull_request and pull_request_target, issues, issue_comment, pull_request_review, schedule, workflow_dispatch), and makes runs. Each job waits for the jobs it needs, is skipped by its if, expanded into its matrix, held to fail-fast, max-parallel and concurrency groups, and started in a sandbox while its workspace has room. Runs, jobs, step states, annotations and logs are kept in D1. In the sandbox, MODE=actions runs a job as GitHub's runner does: run steps in bash, sh, python or a custom shell; JavaScript and composite actions fetched from GitHub; actions/checkout done natively against g1t; the ${{ }} contexts, the GITHUB_* variables and files, workflow commands and masked secrets. The image gains sudo and GitHub's /home/runner layout. Secrets (sealed) and variables belong to a repository or its workspace. The API gains 14 operations on GitHub's own paths under /repos/{owner}/{repo}/actions, and agents may read runs and logs. A run on a pull request's head is a commit status there. Pending statuses hold a merge and the lifecycle; failed ones refuse the merge and send a g1t agent back to fix the cause, using those tools.
No changes