Closed aantipov closed 1 year ago
Updating to cloudflare/pages-action@v1
worked for me.
We just reverted the commit for this, and will release v1.4.1 now.
@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.
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.
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
@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/
Thank you both!
@WalshyDev, here's my assessment of what went wrong with #56 for these users:
gitHubToken
to enable GitHub deployments and deployment statusesbranch
to a "virtual" branch name that does not match a real branch in the repository (!)branch
to be the name of a real branch, and failed if it was notI 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.
@aaronadamsCA I can explain it. Fake branch name maps to a subdomain. Having secrets specific to the environment happens to be useful. ;)
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.
@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.
Latest
v1.4.0
introduced changes to how "branch" prop is handled https://github.com/cloudflare/pages-action/pull/56/filesIt 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 emptyDeployment is triggered by a
pull_request
Hot Fix: specifying
v1.3.0
fixed the issue