I would really like some love for shields/badges similar to https://shields.io/ . A few shields I had in mind: Build Status Build Error/Warning Count Build Lighthouse scores

Sometimes, creating a cold cache can take a long time. Sites that take up to 90mins to create a cold cache are out there. Pressing that clear cache button is a very risky thing to do, if you run one of these sites. I myself have ran into the situation where I cleared the cache, my site wouldn't build anymore because of bugs/timeouts/X and your site would be stale for hours. Potentially running misinformation (about stock for example). So I'd like to propose being able to creating a new cache, while still being able to incremental build the current site. A way in which this could be achieved would be to have something even more awesome: being able to promote a build to production. This could be branch deploys, a different site, but I guess being able to run a cold build on the background would still fit this use case best.

Add support for reporting deploys back to GitHub using the Deployments API ( https://docs.github.com/en/rest/deployments/deployments ). This would unlock the ability to protect PRs based on deployment rules, and to be able to use GitHub Actions based on deployment status.

It would be nice to be able to customize the payload and request method (i.e. GET/POST) of the outgoing we hook notification. I'm trying to set up Algolia DocSearch crawler on GitHub Actions after a successful build on Gatsby Cloud.

We've started to hear the request for integration with Azure DevOps on Gatsby Cloud over the past few weeks.

We have context variables in our Gatsby-node builds and would love to have context support in Filesystem Routes API as that would make the code much cleaner

Users should be able to set both the NPM and Node version for their sites on Gatsby Cloud

I'd love a way to easily integrate our observability tooling (New Relic) to be able to see / query data for: * builds (how long is each build, average build times, where is the build spending the most time, etc) * logs of http traffic / requests to serve gatsby files to browser something like netlify's log drains would be dope. https://docs.netlify.com/monitor-sites/log-drains/

Currently, you have to click 'History' next to a specified build before you can choose to 'Trigger Build'. When you click on the build title itself, it takes you to a different view that doesn't have such option. Also, the UI for 'Trigger Build' and 'Clear cache and build' should be two buttons next to each other. It makes no sense that one is tucked away in a dropdown menu.

We often have the need to get preview content to go with our PR builds. This means we need one env variable to be different for this context. Previews don't help in this case because they're always based on the master branch. Having a third context for PR builds would fix this. I was told the workaround for this is to create a new site which would allow us to create a new list of env vars. While this will work, it is not ideal and also with every PR that we open and every push, a build will be triggered on both sites. (ie wasted resources on gatsby servers!) Also I have a super awesome suggestion for the environment variables. Just have one list, then for each context provide the ability to override the variables from the main list. Having to keep a list up to date and accurate in multiple places and in multiple sites is an aggravating chore. But having this feature would bring me much joy. Netlify has this feature ( https://docs.netlify.com/configure-builds/environment-variables/#declare-variables ) however you must add the variables in a file that is checked into your repo, which helps, but doesn't work well because most often the variables have sensitive information that you can't expose like that.