When someone opens a PR in the GitOps repo managed by CG, CG could run through every deploy it would do but with --no-execute-changeset and then post the JSON output of describe-changeset calls back to the originating PR. This would make the PRs incredibly reviewable, as you can see exactly the infra changes that would occur if merged.
I think this would require re-architecting the S3 side of things somehow. IIUC, there is presently a single bucket with a single state that triggers a deploy when changed. We would somehow need to synchronize the branch's version of things in a way that accurately triggers on what differs, but without actually persisting. If there's a less disruptively way to add this feature, do let me know.
This would also not work if you push a PR that has dependent changes across stacks -- though I don't think that's particularly well-supported even when actually executing the deploys today.
When someone opens a PR in the GitOps repo managed by CG, CG could run through every deploy it would do but with
--no-execute-changesetand then post the JSON output ofdescribe-changesetcalls back to the originating PR. This would make the PRs incredibly reviewable, as you can see exactly the infra changes that would occur if merged.I think this would require re-architecting the S3 side of things somehow. IIUC, there is presently a single bucket with a single state that triggers a deploy when changed. We would somehow need to synchronize the branch's version of things in a way that accurately triggers on what differs, but without actually persisting. If there's a less disruptively way to add this feature, do let me know.
This would also not work if you push a PR that has dependent changes across stacks -- though I don't think that's particularly well-supported even when actually executing the deploys today.