I'm leaning towards a single

pants.yml

workflow, that does install/setup, then runs test/lint and package, against targets that have changes. Then on main runs publish for changed targets. That seems straight forward with pants. When deploying we have post-publish step we need to apply, so would need to know which targets were published (and which were docker), then run those against another GH action to trigger deploys • I was thinking about capturing the output of publish to work out the deploy targets, i can do this with bash but it feels hacky. • I'd also need to limit that to docker targets, to handle publishing packages separately, but using

--changed-since

prevents using other target filtering rules/paths An alternative, would be using an initial job to spin up the env, run tests, and then store that env as an artifact, then a matrix based on the changed targets, which would need to pull env back for publish/deploy. Our pants cache in GH actions is ~4GB, so that feels pretty heft to ship around between jobs...

How are you distinguishing building docker vs packages?