core
core copied to clipboard
Filter by deployment status
Is your feature request related to a problem? Please describe.
By default Cloudflare Page's builds are triggered on each commit/PR to the configured production branch. This means that the Deployments page on Nuxt Hub will show a list >= commits/PRs to that branch.
Although the majority of times we could be interested only in the latest builds, it could be useful to be able to filter based on a particular deployment status, for long term debugging (Checking only canceled or idle or failure).
Describe the solution you'd like The addition of a SelectMenu to be able to pick what statuses to show or not, will all statuses selected by default (since @Atinux has already pointed out that this is would be only client side).
Additional context
This idea came to mind when setting up a test project, that I know I will handle it mostly in a single branch, with a good number of commits just to test features here and there, that wouldn't require a build. To do so I've disabled the automatic builds from the Cloudflare Page Settings for that particular project, and configured a Github action that will trigger a Cloudflare Deploy Hook whenever I decide to.
But now there will be a lot of idle builds, since Cloudflare will detect those commits, but not fire a build.
Describe alternatives you've considered
Change the idle badge color to gray to match the canceled one, or more simply make it different from the failure color (since, to my understanding, a deployment is tagged as idle when ready but not fired).
We changed the idle badge color to gray so far.
We are still thinking about the ability to filter on client-side but the pagination might be very tricky to keep a good UX.
Will contact Cloudflare to see if they can support filtering by status on their API 🤞
Agree. Lets see if it is something they could add, otherwise it would be simpler to leave as is, since I don't imagine this could get much attention
Hi @Sandros94 👋
I work at Cloudflare, @Atinux contacted us regarding this and it should be fairly easy to implement the filtering on our side, I'll take a look into this soon 🙂 :+1:
Hey @Sandros94, just to keep you updated, I did have a look at our internals and this unfortunately does not really look as easy as I initially thought 😓
it would require a bunch of refactoring and the one described here is the only use case we have for this
I don't have too much capacity to spend much time on it so it might take a bit... or it could actually turn out complex enough not to make too much sense for us to implement in on our end (if there's no more demand for it)...
so it's a bit up in the air right now, but I will still try to see if I can help here 😓 🙏
@dario-piotrowicz totally understandable! It is such a niche use case that If the game is not worth the candle, so be it.
While, if it is possible to hang it for a later review I'm also totally ok with that. You know how to give me an update 😁
@Sandros94 thanks so much for your understanding! 🙏
yeah I'll keep you posted when I have news 🙂👍
👀