(feat): Use existing wrangler installation when appropriate

[AdiRishi]

Resolves #199 #259

Rationale

The code added to this PR has three notable behaviours

1. The installWrangler function now checks for existing wrangler installation. It does so by running the wrangler --version command
2. If the command is successful and the version returned is exactly equal to the required version as per config, the wrangler installation step is skipped
3. If no wrangler version was provided to the config of the action, and a pre-installed wrangler exists, the action will use the pre-installed wrangler
4. The above two steps are wrapped in a try/catch so as to prevent any negative behaviour from this change

The decision to check versions seems sound to me, as it is entirely conceivable that users of this library want to install a newer wrangler version in CI than the pinned version in their repositories.

Just to remind everyone, wrangler --version output can look like this

 ⛅️ wrangler 3.27.0 (update available 3.28.0)
-------------------------------------------------------

Testing

• I've added a new folder in tests to run this action against a directory with pre-installed wrangler. This test won't fail if something goes wrong, but we can eye it's output to check things work.
• I know the above test method is a bit sub-par. Happy to hear more ideas on how we can test better. There are a few options here, but not sure how detailed we want to go.

[Cherry]

Reducing the time this action takes to run would be awesome!!

• If the command is successful and the version returned is greater than or equal to the required version as per config, the wrangler installation step is skipped

This specific part of this addition concerns me however, as it would be a breaking change.

Today, specifying wranglerVersion in the config of this action is a hard-set version, and not just a semverGt check, and as per the docs:

[...] 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

As a real-world example, I use the latest wrangler 3.28.x when developing locally, but pin my version in CI to 3.15.0 to workaround secrets issues as per #209. I believe this specific problem is resolved now, but it's not uncommon to want to pin to a specific and reproducible older version in CI, even if that version when developing locally is a little more flexible.

[AdiRishi]

Apologies for the delay in responding, got busy with something else.

@Cherry thanks for the comments, I didn't consider the exact version requirements for wrangler.
Due to the fact that this action pins a "default" wrangler version, I didn't want the behavior to check the pre-installed version against it. That would result in users of this action having to constantly update and keep the wranglerVersion config in sync with whatever they have in package.json

To solve this, I've added some detection in the code to see if a user provided wranglerVersion or if we're using the default.

• If no wrangler version is provided and there exists a pre-installed wrangler in the folder, the action will now use the pre-installed version.
• If a wrangler version was specified, the action will check for an exact version match or else install the requested version

[AdiRishi]

Hmm, I looked into the test failure. It seems unrelated to my change? From looking through the code and the action output I would say that the CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID secrets have been accidentally removed from this repository.

We can see that in the ./run output

 with:
    workingDirectory: ./test/environment
    environment: dev
    preCommands: npx wrangler deploy --env dev
    secrets: SECRET1
  SECRET2

It doesn't list the accountId or apiToken field. What we would expect to see if they were present is something like this

 with:
    accountId: ***
    apiToken: ***

[AdiRishi]

Hello 👋
It's been a while since the last update, just want to bump this. Is anyone looking at this PR?

[petebacondarwin]

Hey @AdiRishi - sorry about the radio silence. We have been rammed preparing for this weeks DevWeek announcements.
It will be back to business as usual next week, so I hope we can get someone to move this forward for you then.

[AdiRishi]

@petebacondarwin a gentle bump again on this PR 🙏

[petebacondarwin]

Hmm, I looked into the test failure. It seems unrelated to my change? From looking through the code and the action output I would say that the CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID secrets have been accidentally removed from this repository.

We can see that in the ./run output

 with:
    workingDirectory: ./test/environment
    environment: dev
    preCommands: npx wrangler deploy --env dev
    secrets: SECRET1
  SECRET2

It doesn't list the accountId or apiToken field. What we would expect to see if they were present is something like this

 with:
    accountId: ***
    apiToken: ***

We can't run the full tests on a PR that comes from a 3rd party fork of the repository. Github Actions blocks sharing secrets with 3rd parties.

[petebacondarwin]

Since this is a test of checking to see if we can use a preinstalled version then it would make sense (with or without a package-lock file) to make this an explicit version.

Suggested change

	"wrangler": "^3.28.0"
	"wrangler": "3.28.0"

[petebacondarwin]

Actually how about we do something really crazy and build a fake wrangler into a node_modules directory here that responds to the version command with a hardcoded version and also supports some fake Wrangler command such as test-wrangler-action. If we end up installing a different version over this then running that command would fail.

[AdiRishi]

That is truely a wild idea 🤯
Any ideas on how to do something like this? The only thing that comes to my mind is something like patch-package.
Would love to know your thoughts.

[petebacondarwin]

Nothing so clever. I can push a commit for you to consider if you like

[petebacondarwin]

I pushed a commit but it didn't quite work in the CI as hoped. I can check again later today.

[AdiRishi]

Very interesting idea, I understand the path you were suggesting now. I've pushed a minor fix that I think will help its run in CI. Its working locally for me at least when I run npx wrangler action-test.
I've also made a fix for the other comment about simplifying the code structure for the if/else logic

[AdiRishi]

Thank you for the review! Some great points, I'll address them soon.

[petebacondarwin]

OK things are looking good. Now that there is logic to reuse current installations of Wrangler, we need to be careful to remove any from tests to avoid leaking between them. E.g. https://github.com/cloudflare/wrangler-action/actions/runs/8970219683/job/24633372708#step:13:17

[AdiRishi]

Understood, I'll take a pass through the existing tests and update them as needed.
Also sorry, I clearly forgot to run formatting in my last few commits haha 😅

[AdiRishi]

@petebacondarwin I was looking through the tests, and we clearly reuse ./tests/base and tests/empty a few times.
In my mind there are two main ways to tackle this.

1. Explicitly deal with the side effects, e.g rm -rf node_modules explicitly as part of our CI steps.
2. Enforce a convention of having a different folder in tests for each step/check we want to do in CI. So we would have things like tests/only-build, tests/build-quiet etc etc

Imo option one adds more mental overhead when writing and running tests.
I think I prefer option two even though it's more duplication it seems like a better convention. What are your thoughts?

[petebacondarwin]

@petebacondarwin I was looking through the tests, and we clearly reuse ./tests/base and tests/empty a few times. In my mind there are two main ways to tackle this.

1. Explicitly deal with the side effects, e.g rm -rf node_modules explicitly as part of our CI steps.
2. Enforce a convention of having a different folder in tests for each step/check we want to do in CI. So we would have things like tests/only-build, tests/build-quiet etc etc

Imo option one adds more mental overhead when writing and running tests. I think I prefer option two even though it's more duplication it seems like a better convention. What are your thoughts?

I think I agree with you in this case. There is a trade-off if the cost of setting up an environment incerases which can cause CI jobs to slow down, but I think we are a long way off here.

[AdiRishi]

Alright, gone through all the tests, setup new test folders where necessary. Hope this runs fine in CI 🤞

[petebacondarwin]

OK I think we are good here. I'll just try running it on a local branch and then merge.
Thanks for the iterations!

[petebacondarwin]

Hmm. I think this is OK. But what happens if this step fails?
We should probably implement a cleanup job that runs on a schedule similar to workers-sdk e2e test cleanup...

[AdiRishi]

Yeah that sounds like something we should add. Do you want me to do it in this PR? If not I'm happy to make another PR after this one to add it in.

[petebacondarwin]

Is this actually a test we want to do? i.e. run the delete command?

[AdiRishi]

That's a great question. We actually do have a delete command below when cleaing up the secret test workers. I figured this change along with another one down below would give us the chance to test out postCommands. Since there wasn't a previous use of it in this script.

[AdiRishi]

OK I think we are good here. I'll just try running it on a local branch and then merge. Thanks for the iterations!

Awesome! Will you be pushing these commits to #260 ? I'm keen to see if it runs correctly myself :)