- Github self hosted runners may not have permissions to write to /opt/
- Also fallsback to trying to extract the deployment-url and deployment-alias-url from stdout when WRANGLER_OUTPUT_DIR is not specified
Updating Semgrep.yml file - Semgrep is a tool that will be used to scan Cloudflare's public repos for Supply chain, code and secrets. This work is part of Application & Product Security team's initiative to onboard Semgrep onto all of Cloudflare's public repos.
In case of any questions, please reach out to "Hrushikesh Deshpande" on cf internal chat.
* (feat): Check for existing wrangler installation
* Add test for pre-installed wrangler
* Add changeset
* Address CR comments - check for an exact wrangler version match
* Tweak the fixture test for the pre-installed-wrangler test
* Simplify if/else logic for checking wrangler versions as per review notes
* fix(test): Fix execution for fake wrangler installation
* fixup! fix(test): Fix execution for fake wrangler installation
* Setup new CI test convention for wrangler-action
* Remove unncessary ts-expect-error comments
---------
Co-authored-by: Peter Bacon Darwin <pbacondarwin@cloudflare.com>
For up to date versions of wrangler, secrets are uploaded via the
'secret:bulk' command, which batches updates in a single API call.
For versions of wrangler without that capability, the action falls back
to the single 'secret put' command for each secret. It races all these
with a Promise.all()
Unfortunately, the single secret API cannot handle concurrency - at
best, these calls have to wait on one another, holding requests open
all the while. Often it times out and errors.
This fixes the legacy secret upload errors by making these calls
serially instead of concurrently.
Currently our release process is kicked off whenever a PR is merged and there are no changesets within the `.changeset` directory. Typically this happens when we intend to publish a release, just after we merge a "Version Packages" PR which removes the changesets and adds the entries to our changelog.
However, this also means that merging any PR without user-facing changes during the period after we've made a release will trigger another release (which luckily fails because the created tag already exists on the remote. See #184).
This change avoids that scenario by fetching tags when checking out the repo. Now when `npx changeset tag` runs, it will see that the tag already exists and skip creating it (`🦋 Skipping tag (already exists): v3.3.2`). The `git push --tags` step will no longer throw an error ("Everything up-to-date"). And lastly, the publish step won't get triggered because the output from `npx changeset tag` doesn't contain the string `"New tag:"`. The action should just finish successfully with nothing to left do.
Fixes#184
If the token isn't specified, wrangler throws this error, indicating the CLOUDFLARE_API_TOKEN should be set, so it's worth being consistent so folks can copy/paste the examples and have it work out of the box:
```
In a non-interactive environment, it's necessary to set a CLOUDFLARE_API_TOKEN environment variable for wrangler to work.
```
Instead of using a mix of `child_process.exec`, `child_process.execSync` and a promisified version of `child_process.exec`, we now (mostly) just use `@actions/exec`. That runs `child_process.spawn` under the hood and handles a lot of character escaping for us. We can also now pass Buffers directly into the subprocess as stdin instead of relying on shell piping.
This ends up fixing a few problems we had where secrets and env var values containing shell metacharacters were being misinterpreted.
Unfortunately, `@actions/exec` doesn't support running with a shell. That means we still have to roll our own wrapper around `child_process.exec` to avoid a breaking change to `preCommands` and `postCommands`, since users might be expecting these to run within a shell.
Also worth noting that we're no longer hiding stdout and stderr from the secret uploading step. We were previously doing this out of an abundance of caution, but it made debugging issues very difficult if secret upload failed for some reason. I feel ok doing this since we're no longer echoing & piping the secret values, wrangler doesn't ever output secret values, and as a last line of defense GitHub masks any secret values that accidentally get logged.
We need to distinguish between when the value is and isn't set in order to perform inference based on lockfile and only fallback to the default of npm if inference fails.
Some of the stderr, stdout, info & groupings can be a little noisy for some users and use cases.
This feature allows for a option to be passed 'quiet: true' this would significantly reduce the noise.
There will still be output that lets the user know Wrangler Installed and Wrangler Action completed successfully.
Any failure status will still be output to the user as well, to prevent silent failures.
resolves#142
Previously, we prevented any error logs from propagating too far to prevent leaking of any potentially sensitive information. However, this made it difficult for developers to debug their code.
In this release, we have updated our error handling to allow for more error messaging from pre/post and custom commands. We still discourage the use of these commands for secrets or other sensitive information, but we believe this change will make it easier for developers to debug their code.
Relates to #137
Utilizing build & tag action to automate the deps and build steps for releasing the Action. Additionally using NCC for the build process to easy compile the deps into a small executable with the JS file.
* Removes dependencies such as Docker, decreasing spin-up time
* Adds community-requested features, including bulk secrets API utilization from Wrangler
* Fixes CI/CD
* Adds testing
* Improves command implementation
* Begins using Node for the Action engine/runner
* Openly discusses all changes with the community
GitHub Discussions opened and Issues monitored
BREAKING CHANGES:
* Docker is no longer a dependency
* Wrangler v1 is no longer supported
Additional related Internal tickets:
Major Version Default: https://jira.cfdata.org/browse/DEVX-632
Rewrite Project: DEVX-804,802,800,632
This change updates the release version for cloudflare/wrangler-action in all examples from `1.2.0` to `1.3.0`.
It also corrects a typo on the last example changing `TOML` to `YAML` based on the code below it.
✨ Zero-config [Cloudflare Workers](https://workers.cloudflare.com) deployment using [Wrangler](https://github.com/cloudflare/wrangler) and [GitHub Actions](https://github.com/actions)
## Usage
Add `wrangler-action` to the workflow for your Workers application. The below example will publish your application on pushes to the `master` branch:
```yaml
name:Deploy
on:
push:
branches:
- master
jobs:
deploy:
runs-on:ubuntu-latest
name:Deploy
steps:
- uses:actions/checkout@v2
- name:Publish
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
```
## Authentication
You'll need to configure Wrangler using GitHub's Secrets feature - go to "Settings -> Secrets" and add your Cloudflare API token (for help finding this, see the [Workers documentation](https://developers.cloudflare.com/workers/quickstart/#api-token)). Your API token is encrypted by GitHub, and the action won't print it into logs, so it should be safe!
With your API token set as a secret for your repository, pass it to the action in the `with` block of your workflow. Below, I've set the secret name to `CF_API_TOKEN`:
```yaml
jobs:
deploy:
name:Deploy
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
```
`wrangler-action` also supports using your [global API key and email](https://developers.cloudflare.com/workers/quickstart/#global-api-key) as an authentication method, although API tokens are preferred. Pass in `apiKey` and `email` to the GitHub Action to use this method:
```yaml
jobs:
deploy:
name:Deploy
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiKey:${{ secrets.CF_API_KEY }}
email:${{ secrets.CF_EMAIL }}
```
## Configuration
If you're using Wrangler's [environments](https://developers.cloudflare.com/workers/tooling/wrangler/configuration/environments/) feature, you can customize _where_ the action deploys to by passing an `environment` in the `with` block of your workflow:
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
environment:'production'
```
If you need to install a specific version of Wrangler to use for deployment, you can also pass the input `wranglerVersion` to install a specific version of Wrangler from NPM. This should be a [SemVer](https://semver.org/)-style version number, such as `1.6.0`:
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
wranglerVersion:'1.6.0'
```
Optionally, you can also pass a `workingDirectory` key to the action. This will allow you to specify a subdirectory of the repo to run the Wrangler command from.
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
workingDirectory:'subfoldername'
```
[Worker secrets](https://developers.cloudflare.com/workers/tooling/wrangler/secrets/) can be optionally passed as a new line deliminated string of names in `secrets`. Each secret name must match an environment variable name specified in the `env` attribute. Creates or replaces the value for the Worker secret using the `wrangler secret put` command.
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
secrets:|
SECRET1
SECRET2
env:
SECRET1:${{ secrets.SECRET1 }}
SECRET2:${{ secrets.SECRET2 }}
```
If you need to run additional shell commands before or after `wrangler publish`, you can specify them as input to `preCommands` (before publish) or `postCommands` (after publish). These can include additional `wrangler` commands (i.e. `build`, `kv:key put`) or any other commands available inside the `wrangler-action` context.
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
preCommands:echo "*** pre command ***"
postCommands:|
echo "*** post commands ***"
wrangler kv:key put --binding=MY_KV key2 value2
echo "******"
```
Set the optional `publish` input to false to skip publishing your Worker project and secrets. Useful in conjunction with pre and post commands. For example, if you only wanted to run `wrangler build` against your project:
```yaml
jobs:
deploy:
steps:
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
publish:false
preCommands:wrangler build
```
## Use cases
### Deploying when commits are merged to master
The above workflow examples have already shown how to run `wrangler-action` when new commits are merged to the master branch. For most developers, this workflow will easily replace manual deploys and be a great first integration step with `wrangler-action`:
```yaml
on:
push:
branches:
- master
jobs:
deploy:
runs-on:ubuntu-latest
name:Deploy
steps:
- uses:actions/checkout@master
- name:Publish
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
```
Note that there are a number of possible events, like `push`, that can be used to trigger a workflow. For more details on the events available, check out the [GitHub Actions documentation](https://help.github.com/en/articles/workflow-syntax-for-github-actions#on).
### Deploying on a schedule
If you'd like to deploy your Workers application on a recurring basis – for instance, every hour, or daily – the `schedule` trigger allows you to use cron syntax to define a workflow schedule. The below example will deploy at the beginning of every hour:
```yaml
on:
schedule:
- cron:'0 * * * *'
jobs:
deploy:
runs-on:ubuntu-latest
name:Deploy
steps:
- uses:actions/checkout@master
- name:Publish app
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
```
If you need help defining the correct cron syntax, check out [crontab.guru](https://crontab.guru/), which provides a friendly user interface for validating your cron schedule.
### Deploying on a "dispatched" event
If you need to trigger a deployment at-will, you can use GitHub's API to fire a `repository_dispatch` event on your repository. By setting your workflow to trigger on that event, you'll be able to deploy your application via an API call:
```yaml
on:
repository_dispatch:
jobs:
deploy:
runs-on:ubuntu-latest
name:Deploy
steps:
- uses:actions/checkout@master
- name:Publish app
uses:cloudflare/wrangler-action@1.2.0
with:
apiToken:${{ secrets.CF_API_TOKEN }}
```
To make the GitHub API request, you can deploy a custom [Cloudflare Workers](https://workers.cloudflare.com) function, which will send a `POST` request to GitHub's API and trigger a new deploy:
Note that `$token` in this code sample is a GitHub "Personal Access Token". For information on how to generate this token, see the [GitHub documentation on "repository_dispatch"](https://developer.github.com/v3/repos/#create-a-repository-dispatch-event).
## Troubleshooting
This action is in beta, and I'm looking for folks to use it! If something goes wrong, please file an issue! That being said, there's a couple things you should know:
### "I just started using Workers/Wrangler and I don't know what this is!"
No problem! Check out the [Quick Start guide](https://developers.cloudflare.com/workers/quickstart) in our docs to get started. Once you have a Workers application, you may want to set it up to automatically deploy from GitHub whenever you change your project. That's where this action comes in - nice!
### "I'm trying to deploy my static site but it isn't working!"
To deploy static sites and frontend applications to Workers, check out the documentation for [Workers Sites](https://developers.cloudflare.com/workers/sites).
Note that this action makes no assumptions about _how_ your project is built! **If you need to run a pre-publish step, like building your application, you need to specify a build step in your Workflow.** For instance, if I have an NPM command called `build`, my workflow TOML might resemble the following:
@@ -2,32 +2,61 @@ name: "Deploy to Cloudflare Workers with Wrangler"
branding:
icon:"upload-cloud"
color:"orange"
description:"Deploy your Cloudflare Workers applications and sites directly from GitHub, using Wrangler"
description:"Deploy your Cloudflare projects from GitHub using Wrangler"
runs:
using:"docker"
image:"Dockerfile"
# Possible values: https://github.com/actions/runner/blob/main/src/Runner.Common/Util/NodeUtil.cs#L9
using:"node20"
main:"dist/index.mjs"
inputs:
apiKey:
description:"(Legacy) Your Cloudflare API Key"
apiToken:
description:"Your Cloudflare API Token"
email:
description:"(Legacy) Your Cloudflare Email"
required:false
accountId:
description:"Your Cloudflare Account ID"
required:false
quiet:
description:"Supresses output from Wrangler commands, defaults to `false`"
required:false
default:"false"
environment:
description:"The environment you'd like to publish your Workers project to - must be defined in wrangler.toml"
description:"The environment you'd like to deploy your Workers project to - must be defined in wrangler.toml"
workingDirectory:
description:"The relative path which Wrangler commands should be run from"
required:false
wranglerVersion:
description:"The version of Wrangler you'd like to use to publish your Workers project"
description:"The version of Wrangler you'd like to use to deploy your Workers project"
required:false
secrets:
description:"A new line deliminated string of environment variable names that should be configured as Worker secrets"
description:"A string of environment variable names, separated by newlines. These will be bound to your Worker as Secrets and must match the names of environment variables declared in `env` of this workflow."
required:false
preCommands:
description:"Commands to execute before publishing the Workers project"
description:"Commands to execute before deploying the Workers project"
required:false
postCommands:
description:"Commands to execute after publishing the Workers project"
description:"Commands to execute after deploying the Workers project"
required:false
publish:
description:"Set to false to skip publishing your Worker project and secrets. Defaults to true."
required:false
command:
description:'The Wrangler command (along with any arguments) you wish to run. Multiple Wrangler commands can be run by separating each command with a newline. Defaults to `"deploy"`.'
required:false
vars:
description:"A string of environment variable names, separated by newlines. These will be bound to your Worker using the values of matching environment variables declared in `env` of this workflow."
required:false
packageManager:
description:"The package manager you'd like to use to install and run wrangler. If not specified, the preferred package manager will be inferred based on the presence of a lockfile or fallback to using npm if no lockfile is found. Valid values are `npm` | `pnpm` | `yarn` | `bun`."
required:false
gitHubToken:
description:"GitHub Token"
required:false
outputs:
command-output:
description:"The output of the Wrangler command (comes from stdout)"
command-stderr:
description:"The error output of the Wrangler command (comes from stderr)"
deployment-url:
description:"If the command was a Workers or Pages deployment, this will be the URL of the deployment"
pages-deployment-alias-url:
description:"If the command was a Pages deployment, this will be the URL of the deployment alias (if it exists) - needs wrangler >= 3.78.0"
pages-deployment-id:
description:"If the command was a Pages deployment, this will be the ID of the deployment - needs wrangler >= 3.81.0"
pages-environment:
description:"If the command was a Pages deployment, this will be the environment of the deployment - needs wrangler >= 3.81.0"
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
github-actions[bot]