Two bugs we are seeing: 1. CI actions recently stopped being triggered by Graphite. We can manually trigger them in Github and eventually Graphite realizes it can merge the PR. This is not impacting all stacks, but seems to happen as stacks get older (repeated merge and restacks). 2. gt fold seems to have a bug, and is leaving behind stale branches that have to be manually deleted. I have filed feedback about both of these issues to aid with diagnosis.

(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>

Thanks for taking a look @Brett Bedevian.

Docs ref here

Got it, this is pretty suboptimal, at least having a flag that lets us keep our local and remote in sync would be great.

Could you share the trigger of your action? Would like to know what its listening for and maybe that helps us understand why its not being triggered

name: Run tests

on:
  pull_request:
    types: [opened, reopened, synchronize, ready_for_review]
    branches-ignore:
      - "**/graphite-base/**"

  push:
    branches: [main]
  merge_group:
    branches: [main]
  workflow_dispatch:

got the new feedback will take a look thanks

Thank you

huh, i was going to say looks like this was just added to the merge queue 🤔 the trigger looks fine, specifically think

synchronize

 is the one we want since its the one looking for new commits as i understand it.

@Brett Bedevian we are hitting this again. I sent feedback

Got the report David, i do see this bottom PR is in a waiting state. OOC what do you see here? https://github.com/armadinsecurity/ares/pull/802#partial-timeline

Three of the checks are "waiting for status to be reported"

Is this a known issue?

I have not seen other reports of this specifically. From our end it looks like we are expecting github to respond.

Three of the checks are "waiting for status to be reported"

To be sure i understand, the github status is

waiting for status to be reported

? so github is also under the impression these havent been run?

the actions were not triggered for this version

Did actions run on previous versions of this PR?

To be sure i understand, the github status is

waiting for status to be reported

? so github is also under the impression these havent been run?

Github appears to be waiting for a run

Did actions run on previous versions of this PR?

Yes

Thanks David but im not sure how much we can do here. As i previously mentioned, we are not explicitly calling the action to run, it is being triggered by an event in github - a commit aka

pull request - synchronize

. We've seen github actions get stuck in this

waiting for status to be reported

state in the past forcing users to push a commit. The fact github itself is expecting the check i think is further evidence of this.

One thing that would help a lot is being able to trigger one off runs from graphite. At first a manual version would be great and then y’all could also look at doing this automatically.

Agreed this would be helpful. I dont know if its actually even possible today, i dont think you can do it from github either. We definitely have an open enhancement request others have asked for this as well I will add you as a requestor to.