Framework CI runners
Framework workflows select the private tagna-local self-hosted runner group.
Read each workflow's runs-on group and labels for the exact operating system
and capability it requires. Independent runner registrations on the same
computer still share CPU, memory, disk and network resources.
Runtime and scheduling
The main workflow sequences quality checks, packed consumer matrices, then browser checks. It limits parallel packed/browser work to reduce contention; it does not reserve the host against other repositories. A failed prerequisite means dependent checks did not run. A queued or skipped job is not a pass.
Provision required Linux browser libraries and disposable-service support on the trusted runner host. Workflows install pinned dependencies and browser binaries; they do not provision privileged OS packages. Windows jobs require PowerShell, Git, Node tooling and access to dependency downloads.
Source-checkout jobs clean their own ignored dependencies and generated output after uploads and release operations. Retain required failure evidence before cleanup. Do not run repository cleanup commands against a developer's unrelated working directory or a shared runner installation.
Access
Persistent self-hosted runners execute repository code with host access. Limit them to trusted contributors and reviewed workflows, keep public/fork access disabled and use isolated or ephemeral hosts where repository trust differs. Giving the npm token only to the publish step does not repair a compromised host.
Framework documentation validation also needs read access to the private
website repository through UDIOT_WEBSITE_TOKEN. It checks out the exact
website SHA stored in the framework submodule. Website verification is
self-contained and does not need a framework repository token.
Runner registrations, startup tasks, host paths and recovery inventories belong in restricted operational records rather than public consumer instructions. After maintenance, inspect online state, requested labels and a fresh workflow run. A retry uses its original workflow revision; YAML changes require a new run of the reviewed commit.
See validation for required checks and publishing for release approval boundaries.