Goal
Define a pipeline file, trigger it from a push, tag, schedule, or button, and follow a run through its steps.Prerequisites
- A build profile connected to a GitHub repository
- mobile_pipelines is enabled on the plan
Workflow
1
Add a YAML file under .stackshift/pipelines/ in your repository, for example release.yml.
2
Press Sync on the Pipelines tab (or push to the configured branch) so StackShift picks up the file.
3
Trigger a run manually, from a matching push or tag, on a cron schedule, or from CI with a pipeline:dispatch token.
4
Watch the run: each step links to its build, submission, or update, and approval steps pause the run until someone approves.
Pipeline file format
A pipeline has a name, triggers, optional concurrency settings, and a set of jobs. Jobs run in the order their needs allow. Supported job types: build (cloud build for android or ios), submit (store submission), promote (pin a release to a channel), approval (pause for a human decision), notify (send a webhook event), run (your own commands in the build container), and ota_publish (export the JavaScript bundle and publish it as an over-the-air update).Triggers
- push: a list of branch names or patterns, matched on every push.
- tag: a list of tag patterns like v*, matched when a tag is pushed.
- schedule: a standard cron expression, evaluated in UTC.
- Every pipeline can also be run manually from the dashboard or dispatched from CI.
Conditions and values
A job can set if: to always(), success(), failure(), or simple comparisons like trigger.branch == ‘main’. Step parameters can reference earlier results with {{ jobs.<name>.release_id }} and trigger details with {{ trigger.tag }}. Only these known values are available; pipeline files cannot run arbitrary code.Concurrency
- Set concurrency.group to make runs in the same group queue behind each other.
- Add cancel_in_progress: true to stop the previous run when a new one starts.
Scripts and over-the-air publishing
run steps execute your commands (tests, code generation, checks) in the same isolated container as builds, with the repository checked out at the run’s ref — but never with access to signing secrets. ota_publish steps export your Expo or React Native JavaScript bundle on the build infrastructure and publish it as an over-the-air update in one step.Expected result
Pushing a tag like v1.4.0 builds the app, waits for an approval, submits to the store, and notifies your webhook — with no manual steps in between.