Trigger policies

Set trigger on a dependency declaration. The default is manual.

# gantrycd:dependency: from_stack=network trigger=always

After network applies successfully, every stack that declares it follows one rule:

A stack deploys automatically when one of its declarations says always, and none says never.

A triggered deployment plans the whole dependent stack, using its configured branch and approval settings.

When nothing starts

The Deploy button stays, but no deployment starts, when GantryCD cannot read the declarations or the applied changes, or when the stack was already deployed earlier in the same chain.

Only normal plan deployments trigger dependents. Pull request promotions and destroys do not.

Advanced: several declarations on one dependency

Skip this unless you declare the same dependency more than once with from_resource.

A declaration limited to one resource is silent about an apply that changed something else — it neither deploys nor blocks. Without from_resource, it speaks for every apply. Being about one resource gives it no authority over a broader one; it only decides which applies it speaks for.

Deploy on every change except one

# gantrycd:dependency: from_stack=network trigger=always
# gantrycd:dependency: from_stack=network from_resource=aws_vpc.debug trigger=never

A change to aws_subnet.main deploys: the never is silent. A change to aws_vpc.debug does not: the never speaks, and it blocks.

A never cannot be overruled

# gantrycd:dependency: from_stack=network trigger=never
# gantrycd:dependency: from_stack=network from_resource=aws_vpc.main trigger=always

Nothing deploys automatically, including a change to aws_vpc.main: a narrower declaration cannot outrank a never. For an exception, invert it — broad always, narrow never, as above.

The Deploy button is not automation

# gantrycd:dependency: from_stack=network from_resource=aws_vpc.main trigger=always

A change to aws_subnet.main offers Deploy but starts nothing. The button follows the declared relationship; only automation follows what changed.

What hidden has to cover

hidden removes the pair from graphs and cycle warnings once it covers every inferred match between the two stacks; a pair with no inferred matches is hidden outright. scope=stack with no from_resource covers them all, so it hides unconditionally. A narrower one leaves the pair drawn when some match falls outside it.

resource and scope change nothing here

They name the part of this stack the relationship belongs to — which decides how it is drawn and what it covers. A deployment plans the whole stack either way, so only from_resource narrows a policy.