mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-15 05:12:28 +01:00
LGUG2Z
bab8f35234
komorebi follows the tip of nixpkgs-unstable, so KWin and Plasma move under it each time flake.lock does, and the pull request that moves the lock runs the slow VM tier only when it is labeled. The `canary` job of ci.yaml, on the weekly schedule and on a manual run, copies the checkout, runs `nix flake update nixpkgs` in the copy and builds every check against the result: the checks that need no virtual machine, listed as the lint job lists them, then the suites of both tiers, listed from `vmTiers` as the discover job does. They run one after the other on one KVM runner, so that komorebi and the guests are built once against the new nixpkgs; the job may take the six hours a hosted runner allows. When a check fails, the job opens an issue titled "Canary: a check fails against the tip of nixpkgs-unstable" with the failed checks, the nixpkgs revision, and the KWin version at the tip and in flake.lock, or comments on that issue if it is open. The same report goes to the job summary on every run. The job's token can read the contents and write issues, nothing more, and the checkout keeps no credentials, so the repository is never changed. The composite action takes `cache: "false"`, which the canary passes. The store cache is keyed on flake.lock: what it restored would be the old nixpkgs, taking disk the guests need, and what it saved would replace the store of the jobs that do use the lock. `just lint` runs actionlint, with shellcheck over the scripts, both from the nixpkgs flake.lock pins, so the lint job and `just check` check the workflows. The steps were run as written on an x86_64 machine with KVM, against a fake gh: GitHub Actions has not run the job yet. CONTRIBUTING.md, docs/dev/vm-tests.md and DESIGN.md say what it does and why.