You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now for very large .cirrus.yml configurations there is a problem of dependency definition. All the depends_on are sparsed across all the task definition and it might be hard to wrap your head around it. What if we'll introduce a new way to define the execution graph via a top-level dependecies definition?
Here is a configuration example of a continious deployment:
# .cirrus.ymldependencies:
Deploy:
only_if: $CIRRUS_BRANCH == "main"requires:
- Check Incidents
- Pushtask:
name: Pushtask:
name: Check Incidentsscript: ... # checks that there is no active incidenttask:
name: Deploy
In case dependencies is used, parser will error if depends_on or only_if are used on tasks so there is strictly two different options to specify dependencies without combining them. This way with the new dependencies we can change behaviour slightly. For example, treat requires as a strict depends_on.
Creating this ticket as a brain dump and a conversation starter.
The text was updated successfully, but these errors were encountered:
Right now for very large
.cirrus.yml
configurations there is a problem of dependency definition. All thedepends_on
are sparsed across all the task definition and it might be hard to wrap your head around it. What if we'll introduce a new way to define the execution graph via a top-leveldependecies
definition?Here is a configuration example of a continious deployment:
In case
dependencies
is used, parser will error ifdepends_on
oronly_if
are used on tasks so there is strictly two different options to specify dependencies without combining them. This way with the newdependencies
we can change behaviour slightly. For example, treatrequires
as a strictdepends_on
.Creating this ticket as a brain dump and a conversation starter.
The text was updated successfully, but these errors were encountered: