cloudflare / pages-action Goto Github PK

Is there a way to specify which branch should be the "production" branch? I do not see a setting if the Pages project is created as a Direct Upload project.

I created a couple of Pages projects when direct upload was made available. In order to get the Pages project to publish to "production", I had to use a branch named production (which I prefer). It worked even when using this GitHub action repository (using "production" would publish to the production environment and any other branch would create a preview environment)

I created a Pages project today. Now, it seems that I have to use a branch named "main" to get it to publish to production.

This'll help folks with monorepos or more non-standard project structures.

Two items should be documented:

• YOUR_ASSET_DIRECTORY: it should indicate that if it's the current directory, it's .. I originally used / as what I wanted to use the root of my repo. However, doing so, the deployment failed with permission errors.
• YOUR_PROJECT_NAME: it should indicate it is the name of the project in pages.

Another item should have its documentation updated: "Get account ID". The first paragraph is confusing.

Let me know if you'd like me to open a PR for all that (or one for each item).

This action allows using branch option, as per readme:

The branch name is used by Cloudflare Pages to determine if the deployment is production or preview

Looks like it correctly passes it to wrangler in the action:

However, this option is not used for determining whether the optional GitHub Deployment is production or not:

Where githubBranch is always:

I would expect if the branch option is passed, it would also be used to determine if the GitHub Deployment is for production or development, for example:

--- const githubBranch = env.GITHUB_HEAD_REF || env.GITHUB_REF_NAME;
+++ const githubBranch = branch || env.GITHUB_HEAD_REF || env.GITHUB_REF_NAME;

Currently I'm deploying to production from a git tag (semantic version), and even though I can create a production deployment to Cloudflare Pages by specifying branch: main manually, I have to disable the GitHub Deployment created by this action, and set it manually instead. You can see my project and actions here: https://github.com/iiroj/iiro.fi

Is there an equivalent mechanism to getting outputs from a wrangler command, similar to this Github Action, for Circle CI? For example, We used the url output of this action to get the pages deployment URL, so we could run Cypress tests against it. I haven't been able to find an equivalent CircleCI Orb, for example.

https://github.com/cloudflare/pages-action#outputs

I don't use the github deployment feature, so would it be possible to add a setting to be able to disable it? This would also remove the need for the "deployments: write" permission.

It would also remove the need to have the action require GitHub deployments write permissions and needing to pass in a GitHub token.

Using this Action to publish to Cloudflare Pages (with cloudflare/pages-action@1, as per the README) still works, but lately has been causing GitHub to show the following warning:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Is there a suggested workaround?

The integration with github comments on the PR -- example: NullVoxPopuli/ember-resources#513 (comment)

But the pages actions does not

I have a GitHub workflow that utilizes two actions: cloudflare/[email protected] and cloudflare/pages-action@v1. However, these actions are not functioning as expected.

name: Deploy 

on:
  push:
    branches:
      - main
        
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    name: Deploy SIYA
    env:
      SENTRY_DSN: ${{ secrets.SENTRY_DSN }}
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
      
    steps:
      - uses: actions/checkout@v2
        
      - name: Restore cache
        id: restore-cache
        uses: actions/cache@v2
        with:
          path: node_modules
          key: ${{ runner.os }}-restore-cache-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-restore-cache-
          
      - name: Install dependencies
        id: install-dependencies
        if: steps.restore-cache.outputs.cache-hit != 'true'
        run: |
          npm run setup
        
      - name: Deploy Slack bot
        id: deploy-slack-bot
        uses: cloudflare/[email protected]
        with:
          wranglerVersion: '3.0.0'
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          workingDirectory: packages/slack-bot
          command: deploy
          secrets: |
            DATABASE_URL
            SLACK_CLIENT_SECRET
            SLACK_SIGNING_SECRET
            SENTRY_DSN
        env:
          SLACK_CLIENT_SECRET: ${{ secrets.SLACK_CLIENT_SECRET }}
          SLACK_SIGNING_SECRET: ${{ secrets.SLACK_SIGNING_SECRET }}
            
      - name: Cache Siya site
        id: cache-siya-site
        uses: actions/cache@v2
        with:
          path: packages/siya-site/build
          key: ${{ runner.os }}-cache-siya-site-${{ hashFiles('packages/siya-site/src/**') }}-${{ hashFiles('packages/siya-site/public/**') }}
          restore-keys: |
            ${{ runner.os }}-cache-siya-site-
            
      - name: Build Siya site
        id: build-siya-site
        if: steps.cache-siya-site.outputs.cache-hit != 'true'
        run: |
          cd packages/siya-site
          npm run build
          chmod 777 /home/runner/work/siya/siya/node_modules/
          
      - name: Deploy Siya site
        id: deploy-site
        uses: cloudflare/pages-action@v1
        with: 
          wranglerVersion: '3'
          projectName: siya-site
          branch: main
          directory: packages/siya-site/build
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          githubToken: ${{ secrets.GITHUB_TOKEN }}     

The workflow above encounters an error message stating "EACCES: permission denied, open '/home/runner/work/siya/siya/node_modules/.cache/wrangler/pages.json'."

Here is the error message screenshot:

An attempt was made to resolve the issue by using the command chmod -R 777 /home/runner/work/siya/siya/node_modules/.cache, but it resulted in an error message stating "operation not allowed."

Here is the screenshot of the error message:

Although it deploy the static asset to pages, but fails the workflow. If someone could assist in understanding the problem and provide a fix or workaround, it would be greatly appreciated.

Hi there! We have a bug in the source code!

I'm using the documentation code,
but a few hours ago I start getting this error on all repo in "Set up job" step

Error: Unable to resolve action cloudflare/pages-action@1, the provided ref 1 is the shortened version of a commit SHA, which is not supported. Please use the full commit SHA 1631a1483b9131d13c61c8c9e6db68f7c7f5d0ee instead.

Maybe the doc should be updated to cloudflare/[email protected] by default

The 1 tag still points to the same commit as 1.1.0 and v1.1.0, so users writing uses: cloudflare/pages-action@1 as documented are still getting the version with the set-output deprecation warning. The tag needs to be repointed to v1.2.0.

Support for the branch option would be excellent! The wrangler cli already supports this, so I'm assuming we can drop it in.

If it's provided it'll overwrite the default, otherwise it can work the way it does today.

This would enable me to perform a production deploy from a tag (instead of being forced to deploy by merging to main).

It would be nice, when making a publish, check if the project exists, and if not. create it.

That will also require to have an extra option to define which the production branch will be.
Like you do with wrangler pages project create PROJECT-NAME --production-branch=NAME-OF-PROD-BRANCH

Use case, we publish multiple sites from a base template that builds on CI for each store.
It will save some time if we just had to add the store details in the CI matrix, and the action took care of the project creation.

Hi! There is a bug with v1.2.0
Error: Parameter token or opts.auth is required
My workflow's step:

...
      - name: publish
        uses: cloudflare/[email protected]
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          projectName: xxx
          directory: .
          # Optional: Enable this if you want to have GitHub Deployments triggered
          #gitHubToken: ${{ secrets.GITHUB_TOKEN }}
...

An error occurs when using it sometime.

STDERR:

npm WARN exec The following package was not found and will be installed: wrangler@2
npm WARN deprecated [email protected]: This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.
▲ [WARNING] Warning: Your working directory is a git repo and has uncommitted changes

  To silense this warning, pass in --commit-dirty=true


✘ [ERROR] ✘ [ERROR] Received a malformed response from the API

  
    <!DOCTYPE html>
    <!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
    <!--[if I... (length = 7002)
  
    POST /accounts/***/pages/projects/wiki-xxl/file -> 502 Bad Gateway
    
    If you think this is a bug, please open an issue at: https://github.com/cloudflare/wrangler2/issues/new
  
  


npm notice 
npm notice New minor version of npm available! 8.5.5 -> 8.10.0
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v8.10.0>
npm notice Run `npm install -g [email protected]` to update!
npm notice 

Currently when using the GitHub Action method of deploying Cloudflare Pages, we are unable to control the alias or environment of the triggered deployment.

Request to add the following parameters:

• Alias
• environment

Without this, there doesn't seem to be much of a purpose to defining a custom URL in the project

Ideally we would be able to define the following

        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: YOUR_ACCOUNT_ID
          projectName: YOUR_PROJECT_NAME
          directory: YOUR_ASSET_DIRECTORY
          # Optional: Enable this if you want to have GitHub Deployments triggered
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          alias: YOUR_ALIAS
          environment: YOU_ENVIRONMENT

This action invokes npx wrangler via the shell:

This causes NPM to re-download and re-install wranger on each invocation of this action.

Notice how there is an NPM warning that it will need to install wrangler.

We're considering migrating from Netlify to Cloudflare Pages - to deploy the same site, nwtgck/actions-netlify takes 2 seconds while this action takes 19 seconds.

If wrangler was in-lined / cached by this action, the deployment would take much less time to finish.

Allow action to pass though commit-dirty arg to Wrangler to suppress warning in logs (or perhaps set it by default?).

Current log output

▲ [WARNING] Warning: Your working directory is a git repo and has uncommitted changes

  To silence this warning, pass in --commit-dirty=true

We have a job that deploys to CloudFlare via direct upload, and we're looking to have it also run some end to end tests using the deployed URL after that's finished. We don't want these URLs universally open to the world as they are production like environments that we want to limit access to. Can we set up an Access Policy in Cloudflare that would allow GitHub Actions to access URLs?

https://developers.cloudflare.com/cloudflare-one/policies/access/

Currently, the description of the builds in Cloudflare are of the form:

Merge 4a618058856d794a1240bfc87c4ddf8294a15f36 into 436b31bdb8e6c124dc51133e6ba2d268e62aecda

It would be great if the PR's last commit summary could be used instead.

For example I don't know how to disable the GH App from continuing trying to deploy my PRs.

I'm using this action to build a Docusaurus page and publish it on CP.
I noticed that an old page that I renamed is still accessible (under the old and new URL).
Are old files not deleted when a new version is published?

In the README it mentions accountId. But there is no information about where to find that in the Cloudflare Dashboard.

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

We are using the environment context in our github workflow to assign a name and url manually. It would be great if it was possible to disable the automatic creation of a deployment and environment and take full control instead, e.g:

  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: 
      name: Preview (PR-${{ github.event.number }})
      url: ${{ steps.publish.outputs.url }}

What would be the proper way to add more environment variables in the use of this GitHub Action? As a way of comparison, a similar Action for Vercel deployments (https://github.com/BetaHuhn/deploy-to-vercel-action) has an optional BUILD_ENV key for inserting these vars, e.g.:

      - name: Publish to Vercel
        uses: BetaHuhn/deploy-to-vercel-action@v1
        with:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN_HUGO_SITE }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID}}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID}}
          WORKING_DIRECTORY: 'public'
          BUILD_ENV: |
            WEBMENTION_IO_TOKEN="${{ secrets.WEBMENTION_IO_TOKEN }}"

Is something like that possible with pages-action, too? Thanks in advance for any related info you could provide.

Every time the Action runs, it fails with the following error

The project name is correct however. In fact, when I go to the Deployments tab in the Pages dashboard, I can see that the deploy was successful.

I am more than a little bit confused.

Currently this action is producing a unique "Deployed to Preview (hash)" that adds to the repository "Environments" section on the sidebar.

I would prefer to limit the number of the environments, probably by project name. So the name should be "Deployed to Preview (projectName)".

This is the current code setting this name:

The action step becomes stuck at random (less than 5% of the time) even after deploying the website successfully. The job eventually fails after the maximum execution time of 360 minutes.

After switching our repository from Yarn to pnpm, npx wrangler@2 fails to download Wrangler. If there is a local Wrangler v2 dependency, the action will run it, but otherwise it fails.

(Yes that's a screenshot of a fork, but it's not behind any commits.)

Our workaround for now will be to install Wrangler in each package that needs to run this action.

Hi

Is there a way to "map" / assign a deployment to a pull request?

Given this config:

      - name: Publish to Cloudflare Pages
        uses: cloudflare/[email protected]
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: xxx
          projectName: yyy
          directory: zzz
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
        id: publish

We normally get this for our pull requests:

It would be nice if the deployment created for this PR would be shown directly in the PR.

• PR comments
• Commit messages
• Alias URLs
• Anything else?

Hey,

So want to use CF pages on a monorepo which the new workingDirectory feature was designed for.
Problem is, to use with monorepos, project has to be defined as a "direct upload" project which doesn't has a production branch setting in it. The only way to do it is to allow this action to have a productionBranch setting which is missing.

Please advise.

TLDR, environment name should be project-name (Production) or project-name (Preview). This aligns much better with environment functionality in both Cloudflare Pages and GitHub, and results in a much better UX.

This action now includes monorepo support, so I can run it for two Cloudflare projects at once. Currently I can't tell these deployments apart, or configure these environments individually in GitHub.

Worse, environmentName unnecessarily includes the branch name. This results in a new GitHub environment for every branch (you can see how messy this gets here). This seems incorrect; in Cloudflare Pages there are only two environments, Preview and Production. I believe this action should follow the same logic and create only two GitHub environments per Cloudflare Pages project.

So, I'd like to propose updating the calculated environment name to always follow the same template: project-name (Production) or project-name (Preview).

I've done this locally, and as you can see the behaviour is much clearer, and mirrors the Cloudflare dashboard.

So that we can put a link in PR comments for a deployment URL for that branch like CF Pages GH app does (e.g. see CF Pages app output vs our custom one):

If I place a _header file in the public folder of my CRA and build locally the _headers file appears in the build folder.

When I run the same build using GitHub actions and upload to Pages the _headers file is not uploaded.

Does pages-action ignore it?

I moved my workflow from on pull_request to issue_comment to save some build minutes. Deployment works fine, but GitHub does not register the deployment anymore and also I get no comment on the pr anymore.

Anyone know how to fix this?

Included a cleaned up version of the workflow beneath.

Edit: I noticed that deployments do get triggered correctly and are shown in ...repo/desployments, but the pull request page claims it didn't:

name: chatops

on:
  issue_comment:
    types: [created]

jobs:
  trigger:
    runs-on: ubuntu-22.04
    steps:
      - name: Trigger
        uses: peter-evans/slash-command-dispatch@v3
        with:
          token: ${{ secrets.CHATOPS_TOKEN }}
          commands: deploy

  deploy:
    runs-on: ubuntu-22.04
    needs: trigger
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm i
      - run: npm run build
      - uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          projectName: my-project
          directory: dist
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.ref_name }}

Right now, Cloudflare's default behaviors for pull_request events are kinda wonky. Because PR events are against a merged commit and this action assumes push events, it's reporting HEAD for the current branch and it also isn't reporting the correct commit to the GitHub Deployments API which results in deployments not showing up on their appropriate PR.

Willing to contribute fixes for both of these.

Currently the only output URL is the unique-per-deployment URL. Each branch also has an alias that could be preferable to visit, especially because of login sessions.

I would combine this with #14 to specify the branch in the case of pull request builds. Because those show up only as HEAD, because GitHub is actually building on a test-merge commit.

Hi,

The action is working great, however we're ending up with a lot of preview sites that are no longer needed as they don't appear to know that the pr is closed/merged.

Is there any ability, or plan to handle the deletion of preview sites when pr's are merged?

Thanks.

Just set this up in my monorepo and immediately ran into this:

I see workingDirectory in action.yml, so I'm not sure what's up here.

To enable GitHub deployments and deployment statuses today, you need to pass in your GitHub token manually:

          # Optional: Enable this if you want to have GitHub Deployments triggered
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

IMO this is a bad API for a few reasons:

• The name gitHubToken doesn't match the behaviour "enable GitHub deployments".
• The value is unnecessary; a GitHub Action can always access github.token.
• Disabling deployments is an edge case; I expect most users would prefer to have deployment statuses.

I'd like to suggest the following changes:

• Set the default value of gitHubToken to ${{ github.token }}. The user would only need to set gitHubToken if for some reason they wanted to use a different token.
• Add new input createDeploymentStatus, optional, default value true.

With these changes, a subset of users could still disable deployment statuses or override the GitHub token, but everyone else would benefit from simpler setup with more default features.

I'm happy to contribute this change if it's desired. I expect it would require a major version bump.

When I run this action, it works but I get this error message in the log:

▲ [WARNING] `wrangler pages publish` is deprecated and will be removed in the next major version.

  Please use `wrangler pages deploy` instead, which accepts exactly the same arguments.

This is the relevant part of my overall workflow file:

      - name: Publish to CFP (cond. - host = CFP)
        if: ${{ env.HOST == 'CFP' }}
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CFP_API_TOKEN }}
          accountID: ${{ secrets.CF_ACCOUNT_ID }}
          projectName: 'static-site-v2' # was 'static-site' (now 'static-site-old')
          directory: 'public'
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          wranglerVersion: '3' # enable Wrangler v3

. . . although I was seeing this before I added the wranglerVersion line to the with section.

Does the deprecation warning mean I need to pass some additional args?

Hi! Testing this out for the first time, hitting some bumps:

Current runner version: '2.291.1'
Operating System
Virtual Environment
Virtual Environment Provisioner
GITHUB_TOKEN Permissions
Secret source: Actions
Prepare workflow directory
Prepare all required actions
Getting action download info
Error: Unable to resolve action `cloudflare/pages-action@1`, unable to find version `1`

I attempted removing the version number, but got:

the `uses' attribute must be a path, a Docker image, or owner/repo@ref

Then setting version 1.0.0, but:

Unable to resolve action cloudflare/[email protected], unable to find version 1.0.0

I'm using this action, and then shortly afterwards I snapshot the site with Percy.io. I've noticed that sometimes, the snapshots fail because it seems the deployment is not fully finished, and the pages all look like this:

Is there a way to cause the action to wait until the deploy is fully finished? Or do I need to use https://github.com/WalshyDev/cf-pages-await in addition to this action?

This code here can cause (albeit relatively unlinkely) a race condition where the values returned for the deployment url, id, etc. are not actually those produced by the previous npx wrangler pages publish command.

We ran into this with our production deployment and a pull request that seemingly happened at the exact same time. Since we use that output to call an external API to register the deployment URL and metadata, this caused a temporary service degradation on our end.

So even if this is indeed a rather rare event, in a large team with a lot of parallel development and github workflows running all the time it's definitely bound to happen every now and then.

I'd suggest to extend wrangler to support a --json flag that outputs machine-readable metadata for all its commands and then use that here instead of the REST api call.

Hey,
i've read through the documentation and source code and it's not clear is it possible to use this action to deploy to preview environment for example for specific pull requests?

It seems to me that it should then require --branch in https://github.com/cloudflare/pages-action/blob/main/src/index.ts#L67
but I am not sure.

If that functionality is not supported I would be happy to contribute with some guidance.

When running the action I get the following error:

Run cloudflare/[email protected]
(node:1948) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
/home/runner/work/_actions/cloudflare/pages-action/v1.2.0/index.js:22[13](https://github.com/OxovaHost/accounts/actions/runs/3638694895/jobs/6141196400#step:7:14)7
    const productionEnvironment = githubBranch === project.production_branch;

I am passing in the github token using gitHubToken: ${{ secrets.GITHUB_TOKEN }}

not working inside of container action :/

with:
    apiToken: ***
    accountId: ***
    projectName: doxygen-[3](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:3)bc
    directory: html
    gitHubToken: ***
/usr/bin/docker exec  90eb791a8e9e29532bfdb63bc7[4](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:4)[5](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:5)ea51bb05c3f87cb3189488e7[6](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:6)[7](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:7)7725[9](https://github.com/RodrigoDornelles/3bc-lang/actions/runs/4518829344/jobs/7958944351#step:5:10)026ff sh -c "cat /etc/*release | grep ^ID"
bash: line 6: npx: command not found
EXIT WHEN NOT EXPECTED

SHELLAC COMMAND FAILED!
Executing: npx wrangler@2 pages publish "html" --project-name="doxygen-3bc" --branch="" in /__w/3bc-lang/3bc-lang

STDOUT:



STDERR:

bash: line 6: npx: command not found


node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "#<Object>".] {
  code: 'ERR_UNHANDLED_REJECTION'
}