Actions-compatible is easy to print on a homepage and difficult to define honestly. Reading YAML is not compatibility. A compatible system must preserve the decisions the workflow makes: when it starts, how jobs expand, which steps run, what credentials exist, and which conclusion reaches the repository.
Runnable treats compatibility as a set of testable contracts rather than a percentage. The workflow parser, action inspector, runtime, and migration report all contribute evidence. When that evidence is incomplete, the answer remains incomplete too.
The result is less dramatic than a promise that every workflow runs everywhere. It is also much more useful when the workflow controls a release.
Compatibility has four layers
The workflow layer covers triggers, expressions, matrices, dependencies, conditions, concurrency, reusable workflows, environments, services, outputs, cancellation, and reruns. The runtime layer covers the Linux image, shell behavior, filesystem paths, process environment, timeouts, and network policy.
The action layer is evaluated separately because an accepted uses line does not prove that the action can execute. Runnable has published contracts for checkout v4 through v6, cache v3 through v5, and artifact v4. Repository-connected inspection can also resolve JavaScript, composite, Docker, local, and nested actions before a final verdict is issued.
The credential layer asks whether the requested repository permissions, secrets, environment policy, and OIDC behavior can be preserved. A workflow that parses correctly but requires authority the installation does not grant is not fully compatible.
The four verdicts are deliberately different
Runnable does not compress uncertainty into a friendly score. The highest-risk construct determines the workflow verdict, so one unsupported dependency cannot disappear inside ninety-nine ordinary steps.
- FullThe inspected workflow and action contracts fit the current Runnable execution model.
- PartialThe workflow is executable, but parser warnings identify behavior that deserves attention.
- Runtime-dependentThe pasted file is insufficient evidence; repository metadata or a resolved action bundle is still required.
- UnsupportedA named construct falls outside the contract and is rejected rather than approximated.
Pasted YAML and connected repositories answer different questions
The public checker can validate the workflow graph and well-known action contracts without an account. It cannot inspect a local action that only exists in your repository or prove what a third-party action bundle calls over the network.
Connecting a repository adds that missing context. Runnable resolves action metadata, required inputs, runtimes, lifecycle hooks, nested actions, and JavaScript bundles. A runtime-dependent result can then become full—or become a specific refusal backed by the resolved source.
The current runtime boundary
Runnable runs Linux x64 jobs on Ubuntu 22.04 or 24.04 images, including explicit 2, 4, and 8 vCPU labels. Service containers and OIDC are supported. Native job containers are not. Jobs have a six-hour platform ceiling, and action inputs outside a covered contract are rejected rather than silently ignored.
Those details will change as the product grows. The important invariant is that the compatibility report and documentation are derived from the same contracts the executor enforces, so a marketing sentence cannot quietly expand the runtime.