I'm running into an issue where graphite's

merge when ready

toggle creates a temporary commit to our main branch, which triggers our deploy job, but then the code is not available on the main branch if you pull main, meaning that if something breaks, you can't see what it is in git. The functionality going on is that graphite does a temp commit onto main, then waits for the deploy job, then actually merges it, retriggering the same deploy job (ideally). I ran into a case where a flaky synthetic that doesn't block deploy caused graphite to never merge the code, and I found the still open PR on github. Is there anyway to disable this "temp merge commit" behavior in graphite? Are there any unique properties graphite uses I can use to block CI from picking up the deploy job? Do other people have this issue of graphite causing drift between what's deployed and what's recorded in git?

(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state

Here is the flow 1. Mark a PR in graphite as "Merge when ready" while the CI test job for the PR is running 2. When the PR test job passes, graphite makes a temporary merge commit of some sort on the main branch 3. CI sees a commit to the main branch and triggers a deploy 4. Despite running a deploy of the new code in CI, said code is unavailable on the main branch via

git pull

5. Synthetic tests, which do not block deployment fail on CI 6. Find the PR in the github interface and merge it for real there 7. Now the real "deploy" job runs, and the code is available on the tip of main as would be expected from "merging" a PR

Hi Christophe, im wonderinf if youre referring to the temporary

graphite-base

branch that gets created during a stack merges rebase. Weve got some information on recommended CI settings here that might help. Let me know if this is the missing link.

My CI is configured to run a deploy when our default branch is pushed to. If multiple graphite PRs are trying to merge in an automated fashion, then the CI workflow will get triggered with fake pushes onto the default branch that do not actually update the branch with the commit push that triggered CI. This results in multiple deploy jobs running for the same "merge" action that graphite is doing - one being triggered without actually having the new code available on the tip of the default branch, and another once it's there for real. Additionally, if the deploy succeeds, but the followup synthetic test job fails (thus the workflow as a whole fails on CI), then graphite will not actually merge the code for real, and the PR will end up stuck in limbo never actually merging onto the default branch.