DagResources
What a whole DAG is granted: the budget its pods share, not a per-pod limit.
interface in bldr
What a whole DAG is granted: the budget its pods share, not a per-pod limit.
The node admits the run against these numbers and then holds it to them — on a native runtime its pods live in one cgroup carrying them, on a VM runtime they become the size of the VM. Declaring them is how a heavy build gets more than the node's default share (a quarter of what it can hand out), and how a light one gets out of the way of its neighbours.
Both are hard limits. CPU: going over costs time and nothing else. Memory: the number covers everything the DAG's pods are charged — what their processes allocate and the page cache of every file they read — because it is also exactly what the node reserved for the run, and a limit above the reservation would be memory nobody accounted for. At the limit the kernel drops cache first; a run whose processes alone need more than it declared is killed, with an error that names this number. So size it to the commands' peak plus the files they keep re-reading, and lower the parallelism inside the DAG rather than under-declaring.
A grant larger than everything a node has for builds is refused when the run is placed, not queued: no amount of waiting makes it fit.
Properties
cpus: number
property
CPUs, as a count — 8, or 1.5. Omitted → the node's default share.
memory: number
property
Memory in bytes. Omitted → the node's default share.