Didn’t get an answer on the Discord, so hoping for better here…
As was noticed on Monday, May 16 (Discord), there appears to be a glitch in the CFP dashboard stemming from the move/removal of the deployment pause option. Even if you disable auto-build-from-Git in both of the separate
Configure Production deployments and
Configure Preview deployments areas under
Builds & Deployments, the main
Deployments dash still shows
Automatic deployments enabled. This also apparently is more than just a GUI glitch; even if you deploy via a GitHub Action (GHA), completely bypassing the auto-build-from-Git mechanism, this still triggers a “
Skipped” indication in the main
Deployments dash, followed after the completion of the GHA by another, more typical deployment indication. (Screen capture below)
So here’s the question, finally . . .
While this is merely annoying for now and isn’t hampering builds, it makes me wonder: does a GHA-triggered deployment even with auto deployments disabled count as two deployments, thus using up the monthly build limit even more quickly?
Obviously, I hope not, but — after seeing this oddity — thought I’d better ask.
I’m sorry but I don’t understand exactly what the question is here. Where does it say automatic deployments enabled still? That sounds just like a UI bug
All Skipped deployments do not count to the quota so in your screenshot only 1 build is counted (the retry - not the skipped)
Hi, Walshy! The automatic deployments still enabled show up in the top of the Deployments tab as shown here:
And, yes, I’m sure it’s a bug that was introduced when the UI got its recent changes, but the double-indicated deployments are what worried me. Thanks for reassuring me that it’s not a double hit on the build limit.
One other question — does doing this via GitHub Actions somehow prevent the usual dispersal across the CDN? I’m near Dallas, Texas, and normally see my site coming from the
DFW POP, but right now it appears to be coming from the Chicago
What exactly do you mean by your site ‘coming’ from a PoP?
Pages websites are distributed everywhere, they’re not served from any particular PoP - if you’re going to a different PoP then that’s just your ISP’s routing taking you there or the usual PoP is currently re-routed for maintenance.
In the headers, the
CF-Ray response more typically ends in
-DFW for me. (Interestingly, the
.pages.dev version still does, but the custom domain version ends in
Edit: It may have something to do with the fact that there’s a Cloudflare Worker in front of the custom domain version but not the
.pages.dev version. Just sayin’.
I guess the thing that made me look in the first place was that, when deploying in the usual direct-from-repo method, the last 20–30 seconds are always depicted as
Deploying to Cloudflare's global network. Since I see no such info within the
cloudflare/pages-action GitHub Action, just wondered if that still happens despite the lack of talkback within the Action.
Note: Isaac McFadyen on the CF Discord has confirmed that all Pages projects get the usual worldwide distribution, and that using a GHA only bypasses CF’s builds but, otherwise, all is normal — as I’d hoped.
Yep can confirm we deploy globally. You hitting another colo is not due to Pages but just general routing things. You can read more about it in these forums, like in this post: Peering - Why don't I reach the closest datacenter to me?
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.