Runnerless concept · not available yet

Shared JavaScript checks across CI workflows

The same repository rule is often copied into several YAML files and slowly drifts. Runnerless is exploring shared JavaScript functions that can be called from either declarative YAML or .runnerless.js. The important boundary is the reusable check logic: teams should be able to review it once and use it consistently.

Design direction for Runnerless. The workflow below is not implemented or available to install.

The proposed workflow

01 /

Separate when from what

YAML can describe an event and the options for a check. JavaScript can express logic that becomes awkward as nested conditionals. A shared module would let either configuration style call the same implementation instead of maintaining two nearly equivalent versions.

02 /

Make dependencies and versions explicit

Reusable policy needs predictable updates. A shared check should have a declared version or pinned source and a clear input contract. Otherwise, changing a central function could silently alter the result across many repositories. Versioning and permission design are part of the planned runtime work.

03 /

Keep the feedback close to the change

A shared module should still produce repository-specific failures that explain which rule failed and where. The existing ci-toolkit config check demonstrates part of this experience: it validates a proposed configuration without executing its actions. Runnerless would need to extend that model to executable modules safely.

A concrete example

Runnerless API preview · subject to change

// .runnerless.js · API preview
import { repository } from "./checks/repository.js";

export default {
  on: "pull_request",
  checks: {
    repository: () => repository({ requireLicense: true }),
  },
};

Know the boundary

What is still to build

This syntax is a preview. ci-toolkit currently has a strict YAML schema with fixed adapters; it does not execute arbitrary JavaScript supplied in .ci-toolkit.yml. Sandboxing, module distribution and permission boundaries remain to be implemented for Runnerless.

Common questions

Will YAML stop working?

The intended direction supports YAML, JavaScript or both. It is an incremental adoption proposal, not a migration requirement.

Can the current toolkit execute my custom JavaScript?

No. Current ci-toolkit automations use a fixed, validated adapter schema.

Runnerless / early access

Want this in
your workflow?

Get early access ↗

Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.