GitHub Actions Compatibility

Supported events, workflow syntax, runners, actions, contexts, and known differences in Trylle CI.

Trylle CI executes GitHub Actions-compatible workflow YAML, but it is not a complete implementation of every GitHub-hosted trigger and runtime feature. Use this page as the migration contract.

Workflow discovery

Trylle discovers YAML workflows under:

.github/workflows/
.trylle/workflows/

The repository Actions policy can allow both roots, allow only .trylle/workflows, or disable Actions entirely. Administrators can also disable individual workflow paths.

Trigger compatibility

Event	Support	Notes
`push`	Automatic	Branch, tag, and path filters are supported.
`pull_request`	Automatic	Defaults to `opened`, `reopened`, and `synchronize`; explicit `types` are honored.
`workflow_dispatch`	Manual	Run from the Actions page against a selected branch or tag; repository write access is required.
`schedule`	Not dispatched	Cron declarations do not currently create runs.
`pull_request_target`	Not dispatched	Do not rely on this event for privileged pull request workflows.
`merge_group`	Not dispatched	Merge queue events do not currently create runs.
Other GitHub events	Not dispatched	No automatic dispatch path is currently provided.

Branch, tag, and path filters

Trylle supports:

branches and branches-ignore;
tags and tags-ignore for pushes;
paths and paths-ignore;
*, **, and ? glob tokens;
ordered ! negation in pattern lists.

Pull request path filters use the authoritative base-to-head comparison when changed filenames are not present in the webhook. If that comparison cannot be resolved, workflows with path filters are skipped; workflows without path filters may still run.

Workflow and job syntax

Feature	Support	Notes
Multiple jobs	Supported	Jobs are planned and displayed separately.
`needs`	Supported	Dependency waves run in topological order.
Job and step `if`	Supported	Includes `success()`, `failure()`, and `always()` behavior used by dependent jobs.
Static `strategy.matrix`	Supported	Cartesian axes plus `include` and `exclude`.
`strategy.max-parallel`	Supported	Limits concurrently admitted matrix shards.
`strategy.fail-fast`	Supported	Defaults to `true`.
`continue-on-error`	Supported	A permitted failure does not trigger matrix fail-fast.
Job outputs	Supported	Downstream conditions and values can use `needs.<job>.outputs.<name>`.
Local reusable workflows	Supported	References under `.github/workflows` and `.trylle/workflows`.
Remote reusable workflows	Supported	`owner/repo/.github/workflows/file.yml@ref`; source access must be available.
Nested reusable workflows	Supported	Maximum nesting depth is four.
Dynamic matrices	Not supported	Matrices derived from step or `needs` outputs are not expanded.
Job-level `container`	Not supported	The workflow is rejected; run containers from a `run` step instead.

Static matrices are expanded before jobs run. Expressions such as fromJSON(needs.plan.outputs.matrix) require runtime output and therefore do not work. Trylle also does not currently impose GitHub's 256-child matrix cap; keep fan-out deliberately bounded.

Actions

Trylle handles several common actions through its compatibility layer:

actions/checkout;
actions/upload-artifact;
actions/download-artifact;
actions/cache and its save/restore entry points.

Checkout and artifact transfer use Trylle-native implementations. Other repository actions are resolved and executed by the GitHub Actions runner when they are compatible with the selected operating system and architecture.

The repository Actions policy controls which workflow roots are discovered. It does not restrict external uses: references inside an allowed workflow.

Runner compatibility

Label	OS	Architecture
`ubuntu-latest`	Linux	x86_64
`ubuntu-latest-arm`	Linux	arm64
`macos-26`	macOS 26 with current Xcode image	arm64
`macos-latest`	macOS 26 with current Xcode image	arm64

Windows labels and unknown selectors are skipped. When consuming third-party actions, confirm that the action publishes assets for the selected runner architecture.

Job-level containers are rejected. Docker is available on Linux runners, so use a command such as:

steps:
  - run: docker run --rm -v "$PWD:/work" -w /work node:22 npm test

Contexts and API compatibility

Common expression contexts include github, runner, matrix, strategy, env, inputs, vars, secrets, steps, and needs. Runtime step outputs written to $GITHUB_OUTPUT can feed declared job outputs and later dependency waves.

GITHUB_API_URL and the github.api_url expression point to Trylle's GitHub-compatible API. The runtime GITHUB_TOKEN is repository-bound and can be used by compatible actions and API clients against that URL.

Permissions and bot identity

Trylle supports a static jobs.<id>.bot extension for jobs that should act as an installed Trylle bot. For those jobs, workflow- and job-level permissions values act as a ceiling on the bot's installed scopes.

Permissions differ from GitHub

Do not treat permissions as a general least-privilege policy for every job's GITHUB_TOKEN. A job without bot runs as the event actor, and the bot-scope intersection does not apply when there is no bot identity claim.

Bot names must be static and reviewable. Expressions such as a bot selected from matrix are rejected.

Current limitations

Limitation	Migration approach
No scheduled dispatch	Trigger the workflow manually or from an external system until `schedule` is implemented.
No `pull_request_target` or `merge_group` dispatch	Use `pull_request` and design permissions for the untrusted-code boundary.
No dynamic matrix from outputs	Declare a static matrix or perform the dynamic fan-out inside one job.
No job container	Call `docker run` from a Linux job.
No Windows runner	Use Linux/macOS or move the Windows stage to another CI system.
Different `permissions` semantics	Use an installed job bot and explicit bot scopes for repository mutations.

See Workflow examples for patterns that stay within this supported surface.

GitHub Actions Compatibility

On this page