The following description is confusing to me.
Preview deployments Preview deployments allow you to preview new versions of your project without deploying it to production. Every time you open a new pull request on your GitHub repository, Cloudflare Pages will create a unique preview URL, which will stay up-to-date as you continue to push new commits to the branch. Customizing preview deployments access By default, preview deployments are enabled and available publicly. In your project's settings, you can require visitors to authenticate using Cloudflare Access to be able to view preview deployment. This allows you to lock down access to these preview deployments to your teammates, organization, or anyone else you specify via Access policies .
So, I look at my deployments and they are a mix of production and deployment. The only setting available is to choose the production branch. The others are preview. So far, so good.
But if this is supposed to be some sort of meaningful workflow tool, then after I change which branch is production, I should deploy it. Unfortunately, there is no way to do that. The only way to cause build/deployment is to push a change to the repo. But if the former preview branch is ready to “be released” to the pubic by making it the production branch, then we can only deploy by making a change.
The assumption here is that the “production” branch is always the same (gosh, then why allow it to be changed?). The triggering change is a merge from a topic change branch, followed by a push. That kinda sorta works but not really.
In Hugo and possibly other site generators it is very important to have a baseURL set so that all of the paths throughout the site refer to the right things. Most of the paths are relative so the setting doesn’t matter, but in some themes there are a couple of things that are absolute. In particular, the site-wide css that Hugo generates lives under the top-level. For a site to render properly, it has to have the baseURL of the actual visible site. If you are using a custom domain–and everyone will (who wants foo.page.dev for their website?) then the production branch has to have the custom domain as its base URL.The preview branches must then use the dev url as their base URL. So far so good…
But, when you merge, you might merge the baseURL. The first time you change the baseURL for a branch it will be in a commit and then you commit it to the production branch. then you fix it in production. Then, you never change the baseURL in production or preview branches and subsequent commits won’t have this. then, it’s ok to keep the branches with different baseurls.
But, it’s a more to set up. The reason to do it is that some builders don’t have a reasonable way to preview new work. Hugo makes it trivial to preview locally–so that is when you do your testing. Then when it’s all fixed and a commit is “good”–you push. It really shouldn’t matter what branch it goes to as long as its the current branch set to be productoin.
You might not work the same way, but this production/preview stuff doesn’t look like it was thought through very well. The fundamental problem is that the production branch can be frozen and very old because it didn’t get a push while it was the production branch (and Pages was looking). For me, this means I do changes and push them, but they don’t go out on the custom domain.
I can adjust to the Pages way, but it is initially awkward. I come full circle: enable a forced build/deploy (to production–the real deal) so the site appears publicly. Then, if I want to use different branch as production (which not everyone will want to do–they may always use the same branch as production) I can easily switch and deploy.
Anyone’s preferences can then be accommodated.
What do you’all think?
es to the site visible on the custom domain. So, the alignment of production to the custom domain–what we want our visitors to see–is sort of random.
After changing the setting for “default” branch, the branch association between production and preview doesn’t seem to change.
Because it is impossible to force a build and deploy, after you change the default branch–the one that might become production at some random interval, you can’t build it to make sure it becomes production and visible.
First, let’s drop the preview production nonsense until you think through how it works.
Second, get some people who actual build web sites to help you design what you are doing so that there is a sensible procedure one can follow.
Third, after the preceding are worked out, redesign the UI so an explicit choice can be made of which branch is production–and therefore which others are preview.
How do we make feature requests for Pages?
Can we get a virtual focus group going so the team has some priorities that reflect customers’ needs?