Hello, we're investigating monorepos and pants, and have come across something we're not sure about. Thought we'd ask here: 1. So far, we have a simple python product (say A). We do trunk based development. Commits usually go to main (or very short lived branches before merging to main), github actions kicks off a build, we run tests, build a container, push to repo, deploy to dev, tests run, promotes to staging, tests run, becomes a candidate for release. A human pushes a button and it gets released to prod. The commit that caused his gets tagged with release-2.10.0 or whatever. 2. We're adding another product (say B). We'll pull out functionality from A to make library X. Team A will work on A and X, team B will work on B and X. 3. Say Joe from team A makes changes and pushes. This shouldn't cause a non-prod release of B to happen (or should it? what does good look like?). Similarly if Jane from team B makes changes and pushed, it shouldn't cause a non-prod release of A. With pants, how do we make sure that Joe and Jane aren't causing some sort of lockstep deployment from happening? Is there some guidance on this? With this setup, our main would look like: A1[R] -> A2 -> B1 -> A3 -> B2 Where these are commits, and [R] signifies the current prod release tag of A. Now let's say, Jane checks in A4 to main. If we look for changes since A1[R], we get B commits in there as well. How do we keep A and B separate?

If something changes in X, do you want to deploy both projects to dev? How many projects are there? Do you want to setup ci in such a way that adding new project is trivial or you're ok setup new ci pipeline for every project manually?

@square-psychiatrist-19087 I think a change in X should trigger both A and B. For now, just the two. But can grow. Ideally, it should be trivial, though if it makes other things simpler, we can do per-project as well. Looking for guidance in this aspect too, I guess.

I think pants should be a good fit here. Before you merge you can run

pants test --changed-since=origin/main

in ci, this will run the unit tests, then you merge the pr. Then you trigger a new ci pipeline on the main branch, you can find the targets to deploy with something like

pants dependents --transitive --changed-since=$LAST_GIT_TAG

and deploy them to dev.

Thanks, @square-psychiatrist-19087. I guess one issue is that we mostly commit directly to main, and the test process kicks off to create a release candidate. so changed-since=origin/main won't help as we'll already be on origin/main. I guess I could compare to last commit, and that should pick up which projects to run against. e.g. if we're commiting to A, if the prior commit were against A or B, A still needs to run.

anyway, changed-since logic is team/project dependent, you can find the files that changed without pants. What pants helps you do is find the deployment targets given the files changed

cool... will have a play and see how it goes.