78
Expose a Gatsby Cloud management API
planned
Activity Feed
Sort by
Bart Veneman
I'd love to be able to recreate this graph that we use internally for tracking builds (success rates, durations, medians, incremental vs. full build, etc.)
- see regressions in build times
- knowing when to investigate and where to look
- see opportunities for build steps to speed up
- onPostBuild syncs are slow, rework them
- createPages takes ages because of X or Y
- give possibiity to make sustainability claims
- Gatsby is claiming it's eco-friendly-ness: let's prove it
- Internally we're working on sustainability too, so I want proof for that as well
Shalaw Karim
I also need that feature. Working on automating headless process right now.
S
Shruti Chaturvedula
planned
Dmitry Pashkevich
I'd like to be able to set environment variables (including for each preview build individually) via an API
Tomás Peralta
I think this would be awesome for non-technical clients that want to check on their deployments' status. I guess the possibility of re-deploying something would be helpful, in case a deploy breaks and wants to re run it just in case before contacting the development team.
Geert Michiels
I really could use this for projects where we need own control over the builds. What I am looking for:
- list of currently queued builds (with details such as incremental/full, source of trigger...)
- possibility to remove a build
- trigger a new build (I know its already partially possible via web hook but still for consistency reasons its nice to have it in same API)
- list of finished builds and their build times (split up in different sections: upload....)
N
Nicholas Martin
Useful for building dashboards, or triggering a rebuild via a slack command.
Kyle Mathews
gatsby-source-gatsby-cloud — recursion!
J
Joel Smith
under review
This sounds like a great idea. What are some of the specific admin actions you'd like to manage via the API?
Henri De Roeck
Joel Smith: I am in a scenario where I expect multiple sequential builds, that will take some time to build. I am creating a function to "bundle" these builds (capture the payload before the Gatsby Cloud webhook is called, call the Gatsby webhook with the combined data every 5 minutes).
To be more efficient, I would like to implement this not based on number of minutes, but based on the status of the current build process (if any) and on the fact if there are queued builds already preseent (in which case I would wait longer). That way, I will not only avoid generating a large number of queued builds but I will also be able to trigger a build once there are no longer any builds running and make max usage of the my resources.
This would require me to do a request to Gatsby Cloud to get a status of the queued builds for my site, like using a management API.
J
Jochen Bertels
Joel Smith My scenario was mostly about being able to update configuration automated for my +200 sites. Enable/Disable cloud or preview builds, change env variables(!), change branch being build, add / remove users, change access for users, ...
Also useful would be an endpoint to fetch the status of builds, history of builds, trigger a new build,...
Shawn Grona
Joel Smith: I have a use case where Gatsby built pages are included in a search service. These pages are created dynamically, I need to know when the build completes so that I can add the particular page to the search service.
J
Joseph Markus
Joel Smith: restarting failed builds
m
matt@b2storefront.com
Joel Smith: We definitely need API for getting information about latest builds s, soo we can easily expose it to clients.
Sean McLeod
Joel Smith: We're building and deploying Gatsby Cloud sites at a large scale (planning on 2000+ by the end of 2023). The three features that would help us the most:
- Managing Environment Variables. Most of the environment variables we use between sites will be exactly the same, with the exception of a handful that will differ between sites. Being able to have a single source of truth for those shared environment variables would be incredible.
- Creating new sites programmatically. Similar to the above, most of our sites will share identical Gatsby Cloud configurations with the exception of things like domains etc. If we could somehow create new sites in an infrastructure-as-code style (JSON or YAML config), this would greatly increase our ability to scale and prevent human error. (Maybe an API isn't necessary for this, we'd be happy to add a config file to our monorepo).
- Triggering builds/previews programmatically. The available webhooks are great when dealing with a singular site, but it would be great to be able to manage builds for multiple sites through an API. We have groups of sites (50+) that share content from an identical data source, so updating these site when the source has changed would be nice. Similarly, it would be great to be able to source build/hosting metrics for all of the sites in our workspace so that we can monitor for errors and problems.