https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# feature-requests
s
This message was deleted.
👀 1
j
we don't currently have an api that exposes this information — but I like the idea!
d
@Jacob Gold does the Graphite Merge queue help with this?
j
It's possible you could try to parse the comment we leave on PRs
I don't think so, but I'll let @David Bradford share his thoughts
d
we’re using Turborepo with remote caching, so presumably we could be saving a lot of CI credits if we could run builds in the Stack sequentially
➕ 1
j
ah, this would help us too!
cool idea
❤️ 1
d
appreciate the fast response. this would be enormous for us. we’d just 
curl
based off of the GitHub SHA to grab the stack information, but i’m sure if it would be possible to add this to the concurrency group on GitHub. thanks again!
ah, looks like it’s not possible:
unless we can somehow get the Graphite stack information into the expression context, it seems this would be remarkably tricky
d
When stacks are being merged in the graphite merge queue, if you turn off "fast forward merge", I believe you will get the sequential building behavior you are describing. It would only be during the merge process though, updates to the stack before merge would still trigger parallel CI runs.
d
oh, interesting. i see. so we’d only get that benefit when merging to 
main
(i’m guessing?)
oh, for 
concurrency
we can use the output of one job as an input to the next, thus getting the effect i’m describing: https://docs.github.com/en/actions/learn-github-actions/contexts#needs-context
l
This would be super useful for me as well, also using turborepo.
d
so we’d have a job that grabs an ID from graphite and sets it as an output, then we’d have a second job that depends on that first job and uses that value in the 
concurrency_group
https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs
Copy code
jobs:
  graphite:
    runs-on: ubuntu-latest
    outputs:
      graphite_stack_id: ${{ steps.api_request.outputs.graphite_stack_id }}
    steps:
      - id: api_request
        run: echo "graphite_stack_id=$(curl graphite api for ID)" >> "$GITHUB_OUTPUT"
  turborepo:
    runs-on: ubuntu-latest
    concurrency:
      group: graphite-stack-${{ needs.graphite.outputs.graphite_stack_id }}
something like this
yeah actually this does exactly what i want ultra fast parrot
Note: When concurrency is specified at the job level, order is not guaranteed for jobs or runs that queue within 5 minutes of each other.
this is the one thorn in this feature, but it doesn’t hurt to try?
@Jacob Gold @David Bradford apologies for pinging you again about this, but a quicker solution (so you don’t have to instrument an entire user-facing API) is to give us a flag in the Graphite UI that when enabled your API will add the stack ID into the GitHub Comment. that way we can refer back to that ID through the GitHub API without needing to go and authenticate through yours.
m
Huge +1 on this feature. It's something that is definitely a downside of Graphite and has me worried about expanding to more team members. My manager has already noticed an uptick in Github Actions credits.
j
We don't have a single ID that represents the stack on our end, we calculate stack information on the fly by looking up dependencies
👍 1
Definitely hear the desire here though
❤️ 1
👍 1
I wonder if there's something you can do by running the 
gt parent
and 
gt children
commands in a github action
e.g. after running 
gt get
to fetch the whole stack
the CLI is definitely not currently optimized for scripting though
👍 1
l
I’d love better scripting support in the cli as well!
👍 1
3 Views
Open in Slack
PreviousNext
Powered by