Native, not a workflow
Cascade is a native MokoGIT feature handled by the forge itself. It replaced the old cascade.yml / cascade-dev.yml Actions workflow that used to run on a runner. Because it is built in, cascading:
- needs no runner, no workflow file in your repository, and no CI minutes;
- does not depend on Sync Profiles distributing a workflow to keep it working;
- is configured as data (rules) on the repository rather than as YAML you maintain.
How a rule is defined
Each cascade rule maps a source branch to a target branch and has:
- Enabled - whether the rule is active.
- Mode - how conflicts are handled:
notify(open a notification / let a human resolve) orauto_resolve(attempt to resolve automatically). - Auto-merge - whether the cascaded merge is completed automatically when it applies cleanly.
A repository also has a cascade default mode (for example notify) used when a rule does not override it. A typical channel-named repository runs a single rule: stable → dev, so hotfixes shipped on stable flow back into dev. Repositories on the conventional model use the equivalent main → dev rule.
How it differs from the old cascade.yml
Old cascade.yml workflow | Native cascade rules | |
|---|---|---|
| Where it runs | On a runner, as an Actions job | Inside the forge, no runner |
| Configuration | A YAML file synced into each repo | Data rules on the repository |
| Upkeep | Kept current by Sync Profiles | Nothing to sync or maintain |
| Conflict handling | Job succeeds/fails | notify or auto_resolve per rule |
The cascade.yml workflow has been retired across the fleet in favor of these native rules.
Related
See MokoGIT: Branch Model & Release Channels for the branch ladder cascade keeps in sync, and MokoGIT: CI/CD & Release Pipeline for how promotion up the ladder works.
Get help
Open a support ticket or call (931) 820-0265.