🚀 Feature Request: Better deployment URL ergonomics

[trappar]

Describe the solution

I'm having an issue with using wrangler for Pages direct uploads. The issue is that my build process needs to be aware of what URL it's going to be available at, and yet I'm only able to get that information once I've already published a build. I know that this feature is resolved when using automatic deployments (via the CF_PAGES_URL env variable), but building that way isn't working for me since it doesn't support everything I'd like to do (or even support my Node 18 environment)

I could imagine several solutions to this:

1 - Add a wrangler command to create a new deployment without actually uploading the files, add another command (or update the existing publish command) to run the actual upload.

Splitting the command into two parts seems like a good way to allow the deployment URL to be known before a build is created, but it also would probably require some pretty major changes on your end, and then it also adds the issue of what to do when a deployment is started but never completes. Not sure how feasible of a request this is.

2 - Add a wrangler command that returns the URL for a given configuration.

I'd assume this would act locally like whatever code is running server side when a deploy is run. I.E.:

• If the current git branch is main, then return the main url "{my-project}.pages.dev"
• If the current git branch is not main, then return the branch url: "{hyphenated-lowercased-branch}.{my-project}.pages.dev"

3 - Add a command that somehow returns the next deployment URL (the hashed one)

I'd imagine that the hash only exists once a deployment is created, and so this isn't possible, which is why I suggested the first option. Maybe somehow this is possible?

4 - Something I'm not thinking of

Maybe there's already some solution that I'm not thinking of? This only really seems to be an issue when working with preview deployments since their URLs aren't stable and aren't based on anything that can be computed locally. I'm definitely open to implementing anything existing...

In fact I've already sort of gone this direction. I've got a build step that I started to create that is:

echo "SITE_URL=$(echo $GITHUB_REF | sed -r 's/refs\/heads\/(.+)/\L\1/g' | sed 's/[^\w]/-/gi') ".${{inputs.cf-project}}.pages.dev >> $GITHUB_ENV

This just seems like a horrible solution to the problem 😬

[half2me]

I'd be very interested in this too. My site uses oauth2 login, and requires a preconfigured callback url. Atm I'm unable to login to any of my preview branches, since I don't know their url. Would be awesome to have a command which could generate the url based on the branch name so I'd know what to set it to.

[schnerring]

I'm interested in this as well.

Just to re-iterate, here's what the docs say about preview aliases:

When a preview deployment is published, it is given a unique, hash-based address — for example, <hash>.<project>.pages.dev. These are atomic and may always be visited in the future. However, Pages also creates an alias for git branch’s name and updates it so that the alias always maps to the latest commit of that branch.

For example, if you push changes to a development branch (which is not associated with your Production environment), then Pages will deploy to abc123.<project>.pages.dev and alias development.<project>.pages.dev to it. Later, you may push new work to the development branch, which creates the xyz456.<project>.pages.dev deployment. At this point, the development.<project>.pages.dev alias points to the xyz456 deployment, but abc123.<project>.pages.dev remains accessible directly.

Branch name aliases are lowercased and non-alphanumeric characters are replaced with a hyphen — for example, the fix/api branch creates the fix-api.<project>.pages.dev alias.

<hash>.<project>.pages.dev is unstable, but <git-branch>.<project>.pages.dev is stable.

The algorithm to generate <git-branch> alias seems to be a bit more involved than the docs state, however.

We normalise as you already know, then if it’s over max length (28) we limit. If there’s no usable chars (we normalised to nothing) then we generate a random branch name with the format “branch-{randomChars}”

It would be really nice if wrangler would expose a "generate branch alias" instead of having to adopt an ugly sed approach.

[schnerring]

For anyone interested, I created a GitHub Action that wraps the JavaScript solution that @WalshyDev posted on the Cloudflare community forums as a workaround until this is (hopefully) integrated into the wrangler CLI.

Here's a sample of how to use it:

name: Build Hugo Site

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.111.3"

      - uses: schnerring/cloudflare-pages-branch-alias-action@v1
        id: pages-branch-alias
        with:
          # git-branch input
          git-branch: ${{ github.ref_name }}

      - name: Build Hugo
        # branch-alias output
        run: |
          hugo \
            --minify \
            --baseURL "https://${{ steps.pages-branch-alias.outputs.branch-alias }}.my-project.pages.dev"

[weiklr]

I think wrangler just needs to have access to cf_pages_ur like cloudflare pages auto deploy,l so we can could run our build step (with nom yarn etc) as a precommand. Then print out the alias and deployed url on GitHub actions and it will be perfect for me.