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.yml
dependencies:
Deploy:
only_if: $CIRRUS_BRANCH == "main"
requires:
- Check Incidents
- Push
task:
name: Push
task:
name: Check Incidents
script: ... # checks that there is no active incident
task:
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.
Right now for very large
.cirrus.ymlconfigurations there is a problem of dependency definition. All thedepends_onare 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-leveldependeciesdefinition?Here is a configuration example of a continious deployment:
In case
dependenciesis used, parser will error ifdepends_onoronly_ifare used on tasks so there is strictly two different options to specify dependencies without combining them. This way with the newdependencieswe can change behaviour slightly. For example, treatrequiresas a strictdepends_on.Creating this ticket as a brain dump and a conversation starter.