Hey team! We are experience a weird behaviour related to a github action workflow. We have the filter branch to not run the workflow for graphite-base branches, but it seems that is causing us an absence of the run and we need to reopen or push another commit to trigger it. I've read this https://graphite-community.slack.com/archives/C02DRNRA9RA/p1769611350587059?thread_ts=1768863467.601789&cid=C02DRNRA9RA And we got the idea, but it seems the base branch change is done after the commit, so the commit(synchronize event) won't trigger the workflow because at that moment the base branch is grahpite-base and after that the base branch is changed. Is that the expected behaviour? Would like to say that is a bit intermitting, it doesn't always happen. Thanks! Will really appreciate any help on this. 🙏

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

since i can't see into your CI configurations, is it set up to run on any branch?

this is the config

on:
  push:
    branches:
      - main
  pull_request:
    types:
      - closed
      - opened
      - synchronize
    branches-ignore:
      - "**/graphite-base/**"

i see that the config only listens to

opened, synchronize, closed

. when graphite retargets a branch, there's a possibility that github fires a

pull_request.edited

event rather than

synchronize

. if that's what's happening, adding

edited

would make CI trigger on the retarget.

edited

also fires for PR title/description edits, so CI will re-run on those too. if that's a concern, adding a condition so your jobs only run when the base actually changes should fix this.

we have a fix(not merged yet) from our side with that, using the edited event as you mentioned, but we read this from your docs https://graphite.com/docs/github-configuration-guidelines#github-actions > We do not recommend triggering CI on the pull_request type

edited

. This action is triggered when metadata about the PR is changed, not the PR itself (that would be

synchronize

). The

edited

event triggers a CI run when the PR below a given PR is merged—as the change of the base branch from the downstack PR to trunk is considered an “edit”. I think our main concern here is if thats the actual expected behaviour, I mean if the recommendation is to avoid graphite base branches, then why we have this behaviour? perhaps that is missing in the docs besides the advice to filter out the graphite base branches? 🤔 We are a bit confused

thanks for that. its my second week so im still learning more about how graphite works with github. after speaking to one of our engineers, you DONT want to add

edited

to the types as stated in our graphite docs. it seems like the issue is that there seems to be some flakiness with Github Actions where force pushing doesn't deliver the

synchronize

event -- which it should. we do have an internal ticket in place for this issue that is currently on our engineers radar.

no worries Josie, thanks for the support here!