Bug: "branch" input bug in v1.4.0

[aantipov]

Latest v1.4.0 introduced changes to how "branch" prop is handled https://github.com/cloudflare/pages-action/pull/56/files

It broke our deployment pipelines in all our projects with "RequestError [HttpError]: No ref found for" error:

As you notice here, when the action sends request to Github to create a new deployment object, the ref prop is empty

Deployment is triggered by a pull_request

Hot Fix: specifying v1.3.0 fixed the issue

[krisgardiner]

Updating to cloudflare/pages-action@v1 worked for me.

[WalshyDev]

We just reverted the commit for this, and will release v1.4.1 now.

[aaronadamsCA]

@aantipov Could you please share the action inputs you were passing to the action when you encountered this error?

I'm trying to figure out how to reproduce this. I contributed #56 specifically so pull_request events would get the correct ref, and it works for me, but obviously failed for a bunch of other people, so I'd like to figure out why.

[aaronadamsCA]

CC @jkorichneva, @felixlublasser, @ivolimasilva, @limakzi, @tamacti - same as above, if you could please share your GitHub Actions workflow where you encountered this issue, I'm trying to reproduce your error so I can fix the original PR.

[ivolimasilva]

I'm using Cloudflare Pages to deploy a version of a web app on every PR, where we pass a custom branch to match the project + PR's number. Here's the workflow using cloudflare/pages-action:

on:
  pull_request:

# ...

jobs:
  # ...
  - id: deploy
    name: Deploy `client` to preview environment
    uses: cloudflare/pages-action@v1
    with:
      apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
      accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
      projectName: ${{ secrets.PROJECT_NAME }}
      directory: ./apps/client/build
      gitHubToken: ${{ secrets.GITHUB_TOKEN }}
      branch: "client-pr${{ github.event.pull_request.number }}"
    env:
      GITHUB_TOKEN: ${{ github.token }}
      CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
      CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

And the error would be:

/home/runner/work/_actions/cloudflare/pages-action/v1/index.js:5857
          const error = new requestError.RequestError(toErrorMessage(data), status, {
                        ^

RequestError [HttpError]: No ref found for: client-pr123

[limakzi]

@aaronadamsCA, same as @ivolimasilva. I have one more conditional deploy to test.*.pages.dev. Mine below.

---
name: Deploy mkdocs

on:
  pull_request:
    branches:
      - main

env: [...]

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment:
      name: test
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11' 
          cache: 'pip'
      - run: pip install --upgrade pip
      - run: pip install -r .python/requirements.txt
      - run: mkdocs build --strict
      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@v1.3.0
        with:
          accountId: ${{ env.CF_ACCOUNT_ID }}
          projectName: ${{ env.CF_PROJECT_NAME }}
          apiToken: ${{ secrets.CF_API_TOKEN }}
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          branch: 'test'
          directory: site/

[aaronadamsCA]

Thank you both!

@WalshyDev, here's my assessment of what went wrong with #56 for these users:

• They have set gitHubToken to enable GitHub deployments and deployment statuses
• They have set branch to a "virtual" branch name that does not match a real branch in the repository (!)

• 56 expected branch to be the name of a real branch, and failed if it was not

I did not expect this, sorry! I had no idea people were using fake branch names when deploying to Cloudflare Pages. I can file an updated PR that ignores the branch input and just uses the real branch name for GitHub deployments.

[limakzi]

@aaronadamsCA I can explain it. Fake branch name maps to a subdomain. Having secrets specific to the environment happens to be useful. ;)

[snorremd]

We use virtual branch names too in our org. This is useful to model persistent environments that are all deployed from the main branch without having to actually maintain separate git branches. Nice to see this reverted in 1.4.1. I definitely see how this change in behavior could happen as branch alias is assumed in the Cloudflare docs to be an actual branch.

[limakzi]

@snorremd I haven't seen such assumption, that branch MUST, by the RFC, match real branch-name; correct me if I am wrong. I would prefer to call it - environmentName. This variable name would fit real behavior better.