Differences from GitHub Actions

Who this is for: people and AI assistants who know GitHub Actions and write Liitora workflows.

Before you start: nothing. The full format is in Workflow file format.

Liitora workflows look like GitHub Actions workflows on purpose, so your knowledge carries over. But Liitora runs business automations, not builds, so some parts work differently. When you use a GitHub Actions key that Liitora doesn’t have, the save is refused and the message tells you what to write instead.

What works the same

• on: lists the triggers, and steps: lists the steps.
• A step has id, name, uses or run, with and if.
• needs: makes steps wait for each other. Steps that don’t depend on each other run side by side.
• ${{ }} expressions, with steps.<id>.outputs, needs.<id>.result, &&, ||, !, == and functions such as contains, startsWith, endsWith, join, toJSON, fromJSON and format. Text comparisons in contains and friends ignore case, as in GitHub Actions.
• Status functions success(), failure(), always() and cancelled() in if:, with the same rules: a failed or skipped step skips the steps after it unless they opt in.
• continue_on_error and timeout_minutes mean the same, with underscores.
• concurrency: with group and cancel_in_progress.
• Actions are pinned by major version: @v1.

What is different

In GitHub Actions	In Liitora	Why
jobs: with steps inside	steps: directly under the workflow	A workflow is one list of steps. Use needs: for parallel branches.
runs-on:	runs-on: self-hosted/<group>, or nothing	Without it, steps run in Liitora’s sandbox. With it, they run on your own runners. Labels such as ubuntu-latest don’t exist. See Run automations in your own environment.
shell: and shell commands in run:	JavaScript in run:	There is no shell. A run: step is a small JavaScript module that runs in a closed sandbox. See Host API for scripts.
Containers and services	nothing	Nothing is installed or started. Built-in actions do the common work: HTTP calls, CSV, PDF, zip, email and webhooks.
env:	vars and connections:	Plain values shared by your workflows are company variables. Addresses and sign-in come from connections.
secrets.MY_TOKEN	connections: or ctx.secrets.get("name")	A secret is never written into the workflow. A connection holds the address and the names of its secrets, and Liitora adds the sign-in to each request. The values stay with people.
Marketplace actions (owner/repo@v4)	platform/, library/ and your company’s own actions	Actions are built-in, from our curated library, or your own. See Action references.
outputs: on a step or job	the action’s own outputs	Read them as ${{ steps.<id>.outputs.<name> }}. A run: script returns an object, and that object is its outputs.
workflow_dispatch	manual: true	Lets a person start the workflow from the app.
repository_dispatch	api: true	Lets a program start the workflow through the API.
push, pull_request and other Git events	schedule:, webhook:, workflow_run:, manual: or api:	There are no Git events. Another system can call a webhook instead.
schedule: in UTC only	schedule: with timezone: and calendar:	Runs follow local time and summer time, and can skip or move on Finnish or Swedish holidays, weekends and your own blackout days.
strategy.matrix	strategy.for_each	The step runs once per item of a list, with each.item and each.index.
Dashed keys: timeout-minutes, continue-on-error, cancel-in-progress, max-parallel, fail-fast	Underscores: timeout_minutes, continue_on_error, cancel_in_progress, max_parallel, fail_fast	One spelling everywhere.
Reusable workflows with uses: ./.github/workflows/x.yml	uses: workflow/<company>/<name>@vN	Calls another workflow of your company, and waits for it unless wait: false.
Retries with extra actions	retry: on the step	attempts, backoff and which failures to retry (429, 5xx, timeout, network).
Nothing	expect:	Raises an alert when the workflow did not succeed by a time of day.

Rules GitHub Actions doesn’t have

• Plain-language names. The workflow needs a name and a description, and every step a name, written for people. Names such as step1 are refused.
• Tests gate activation. Every version carries test cases. A version can only be activated when its tests pass and the required minimum is met. See Test case format.
• A person approves. By default a person must approve each new version before it runs for real, and the author of a version can never approve it.
• Versions never change. Each save makes a new version. You can compare versions and roll back.
• Outbound calls are limited. Requests use HTTPS and public addresses only. Private and internal addresses are blocked, and redirects are not followed by default.
• No credentials in the file. A password or key written into YAML, a script or a test is found and refused for AI assistants (and warned about for people).
• Strict YAML. Anchors and aliases are refused, and so is any key Liitora doesn’t know.

Next steps

• Workflow file format
• Built-in actions
• Host API for scripts