https://pantsbuild.org/ logo
Join Slack
Powered by
I have a design question that will be key to under...
# general
i
I have a design question that will be key to understanding if pants is a good choice for us. Besides the benefits of parallel builds, only building the parts that are unchanged, we want to be able to only deploy changed parts of the monorepo. So how does this work in an ephemeral build system?
We currently test and build the whole monorepo with every change in Google's Cloud build. In our ideal state pants would: • detect a change to a branch • test • create new packages for the changed parts of the repo • some magic where we know which deployments to run based on the changed packages. We do all this today without the benefit of knowing the changed parts of the repo so we deploy everything
my reading and experiment list for the day 
pants --changed-since=origin/main goal
Is there some way to keep the 
.pantsd
folder available so it knows what to compare to in stateless systems like Cloud Build? At least that is how I understand this to work
s
pants doesn't know anything about the target system it deploys to. You can figure out changes based on git changes though, something like
Copy code
pants --changed-since=origin/main dependents --transitive | 
  xargs pants peek | 
  yq -p json '.[]|select(.target_type == "helm_deployment").address' | 
  xargs pants experimental-deploy
i
awesome, i'll try that out
a
We settled on a flow where we split our code into components and from the initial step, we split into multiple workflows. Each component then gets a list of targets that are relevant to it, and it just runs test, package and release on them.
It might've been inspired by our misguided decision to move to circleci, but you do get the advantage of building things in parallel.
Everything held together with lots of hacky bash scripts, of course.
7 Views
Open in Slack
PreviousNext
Powered by