This will ensure that wrangler-action will use the latest compatible version of Wrangler if not specified otherwise.
There are two ways to lock down the version of Wrangler for this action:
- Specify the required version in the action's parameters when implementing it in your Github Workflows.
- Add a dependency to a specific version in your package.json of the project being deployed via this action.
* (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.
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
