Are there any recommendations for setting up CI ar...
# how-do-i
i
Are there any recommendations for setting up CI around a Graphite-based workflow? Currently, each
gt sync; gt ss
will trigger many GitHub Actions runs, which burns through our minutes pretty quickly. Is there perhaps a way of only running Actions for the top of the stack? I've thought of using a workaround where I install Graphite in CI, do a
gt get
then try
gt up
, and if that fails then run the CI pipeline, but that's really not ideal at all and there are all sorts of edge cases where that fails. Is there maybe an API I can hit to get Graphite metadata about a branch, including whether it's the top of a stack?
j
(disclaimer, we haven't tried this — we rely on `turborepo`'s remote caching to save on ci cost) One thing you might try is checking if there are any open branches with the current branch as their target, and skip CI in that case. However, any solution like this seems risky as if you merge in just half your stack, it won't yet have passed CI. We don't expose an API currently, unfortunately.
i
We also use Turborepo, but there's still a lot. Vercel will also trigger a build for each one, which is a massive pain as concurrent builds are limited. And yeah, that solution is a hacky workaround too 😅
z
You can also add [skip-ci] manually to commit messages for commits you don’t want to run CI for - I’d be curious if it could be something we do automatically in the CLI @Jacob Gold
j
the problem with
[skip-ci]
though, is that if the check is required it won't be mergeable
i
I'll have to use the open branch check for now, I think. It's not ideal, and it won't work when submitting a load of new branches, but it should be better than nothing