The CI runner was a hive deploy module: hive-ci.nix ran it beside the forge, and hive-c0re registered it through the forge's admin API with the `core` token, writing the registration token through hive-priv. It could only run on the forge's host, and it kept an admin-scoped forge token on a hive. Now the runner is a swarm service: - swarm-ci-runner.nix runs it in a `swarm-ci-runner` container on the host that sets deploy.ci-runner.enable, reaching the forge by name. It needs neither the forge nor a hive there. - swarm-controller reads the forge's runner registration token with its own admin token and writes it to swarm/services/ci-runner/ registration-token whenever it differs from what it last wrote. Its grant on that path is create/update only. - The runner's own leaf (CN swarm-ci-runner, role and policy of the same name) reads that one path. swarm-bao-ci-runner.service fetches it into the runner's EnvironmentFile and restarts the runner on a change. - A pre-start step removes .runner when the daemon's journal since its last start holds Forgejo's "unregistered runner" refusal (the daemon exits 1 when its startup Declare gets it), or when .runner names another forge address; upstream's pre-start step then registers again. Removed from the hive side: hive-ci.nix and deploy.forgejo.ci.*, forge/ci_runner.rs, PrivRequest::RegisterCiRunner and its handler and ReadWritePaths entry, InfraContainer::Ci with hivectl's --ci and the dashboard's hive-ci journal entry, HYPERHIVE_FORGE_CI_ENABLED, and read:admin,write:admin from CORE_TOKEN_SCOPES: nothing else in hive-c0re calls /api/v1/admin/*. The old ci options, under both swarm.forge.ci and deploy.forgejo.ci, now fail evaluation naming deploy.ci-runner. The forge's half of the old ci.enable, the actions/checkout mirror and DEFAULT_ACTIONS_URL = self, is deploy.forgejo.actionsFromSelf. Closes #4954
50 lines
2 KiB
YAML
50 lines
2 KiB
YAML
name: coverage
|
|
|
|
# Nightly plus manual dispatch. The report is uploaded as an artifact rather
|
|
# than printed into the run log, so a scheduled run leaves something to fetch.
|
|
#
|
|
# ⚠️ The hour is deliberate: at the default job capacity of 1
|
|
# (`services.hyperhive.deploy.ci-runner.concurrency`) this job holds the
|
|
# runner for its whole timeout and everything else queues behind it.
|
|
#
|
|
# Separate from ci.yml because a `workflow_dispatch` trigger there fires every
|
|
# job in that file, and this must not run per pull request.
|
|
on:
|
|
workflow_dispatch:
|
|
schedule:
|
|
- cron: "0 2 * * *"
|
|
|
|
jobs:
|
|
coverage:
|
|
name: cargo llvm-cov
|
|
if: vars.PUBLIC_FORGE != 'true'
|
|
runs-on: ${{ vars.PUBLIC_FORGE == 'true' && 'nixos' || 'hive-ci' }}
|
|
# Above the 30 min `nix flake check` allows, because instrumented
|
|
# builds are slower than the ordinary ones and this starts from a
|
|
# cache that the normal jobs never populate.
|
|
timeout-minutes: 60
|
|
steps:
|
|
- uses: actions/checkout@v3
|
|
- name: coverage
|
|
# No threshold and no `--fail-under-lines`: a coverage gate
|
|
# mostly teaches people to write assertion-free tests that
|
|
# execute lines. The report is the deliverable; the number is
|
|
# for a human to look at.
|
|
#
|
|
# `--workspace` because the interesting holes are in the crates
|
|
# nobody runs directly, and the per-crate default would hide
|
|
# exactly those behind a green summary for the one crate someone
|
|
# happened to name.
|
|
#
|
|
# `pipefail` or the step reports `tee`'s status, and a failed run
|
|
# uploads an empty report as a success.
|
|
run: |
|
|
set -o pipefail
|
|
nix develop -c cargo llvm-cov --workspace --summary-only | tee coverage-summary.txt
|
|
- name: keep the report
|
|
# `always()`: a failed run should still leave its partial output.
|
|
if: always()
|
|
uses: actions/upload-artifact@v3
|
|
with:
|
|
name: coverage-summary
|
|
path: coverage-summary.txt
|