https://linen.dev logo
Join Slack
Powered by
Good afternoon team :slightly_smiling_face: In th...
# report-bugs
k
Good afternoon team 🙂 In the documentation it is recommended to ignore graphite-base branches, but recently when creating stacks, the last commit ends up stuck on a graphite-base branch and so the CI never triggers making the PR un-mergeable. In some case 
gt submit --always
is helping but for some PRs it is completely stuck. I'll add an example in the thread. Any recommendations and is it a known issue ? 😄
✅ 1
image.png
p
(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>
Hi Kenny, there are 3 reasons Ive found that a PR in a stack would be stuck pointing to 
graphite-base
1) If you make changes to something downstack but do not submit the entire stack 2) our automatic rebase fails (mostly from a detected merge conflict) 3) more of an edge case but i have seen github fail to complete the rebase that we request from the API when 
gt submit
is called. This would manifest in local stack looking correct but github / graphite ui pointing to base. 
gt sync && gt ss
should trigger a restack locally and resolve these. In the case it does not the path of least resistance would bego to the PR on GitHub and change the base branch from 
graphite-base/x
to 
actual-parent
using the "Edit" button next to the title.
k
Yeah I faced those cases but the one I mention in the bug above seems to be a systemic. The graphite UI extension and CLI are showing that everything looks good, 
gt submit --always
sometimes unlock it but the main issue is indeed the base branch 😄 Especially on big stacks it is appearing it seems. In my case gt sync was a noop because I was already on the most recent trunk base
p
I would reccomend to leave the ignore base branch on in your CI. It will fail almost every time.
Could you tell me how you are triggering this bug systematically? provide repo name and pr number this happened on recently would help to maybe.
k
I meant systemic so that it was happening either in graphite or github backends I do not have a clear repro but one sample is this PR, I managed to unblock it after 3-4 gt submit --always and now it got rebased, the base branch is master but the CI is not being triggered
👍 1
So I had to run "git commit --allow-empty -m "chore: retrigger CI" + gt submit 😄
👀 1
p
ah sorry i misread! i do wonder if this is a ratelimit when submitting a large stack and it does not finish. glad you found a workaround
k
Ratelimit on graphite side or on github ? 😄
p
github.
Feel free to run 
gt feedback -d
to send us your CLI logs i can take a look if everything went as expected from CLI perspective
k
I uploaded it as 
PR blocked with wrong base branch a few times graphite-base branches - Kenny slack report-bugs
But the PR was already unblocked, not sure if the logs will be meaningful 😄
👍 1
Thank you for your help!
p
okay lookign at the logs it seems like the restack attempts you did failed (potentially silently) i see in the logs 
Merge conflict in libs/api/modules/partner/testing/src/lib/controllers/update-partner-notifications-settings.spec
which would account for why the submit --always didnt make a difference. Are you using only the CLI or also the VSC ext?
k
Both but primarily the extension 😄
But I did not have to solve conflicts in the end
8 Views
Open in Slack
PreviousNext
Powered by