Fix tests on windows

[mquinnfd]

Ensuring Windows test runs use the correct version

Updates the GH Action tests for Windows/Linux, aiming to produce predictable failures of tests in controlled scenarios (i.e. using the correct Windows package).

Would recommend trying this out though, I still think there's some weird behaviour of some of these process-based tests, where the Windows vs. Linux tests do not operate or fail identically, perhaps this is intended.

I suspect this can be fixed more cleanly by sorting the venv mess in the pipeline and having the windows GH Action runner be in the correct, activated venv instead of doing this, so will raise a separate issue for that.

Addresses #2796

Some testing of the breaking changes submitted in the issue by @andrewbaldwin44

• Pass https://github.com/mquinnfd/locust/actions/runs/9889338165
• Fail https://github.com/mquinnfd/locust/actions/runs/9889352748
• Fail https://github.com/mquinnfd/locust/actions/runs/9889369296
• Pass https://github.com/mquinnfd/locust/actions/runs/9889376225

Major

• Update the Windows-only step to create and install a binary version of the package, to use in the tox-based tests
• Add GH Actions matrix test value to allow front end build skipping for certain envs
• Pass the front end build skip env var to tox for fail fast tests

Minor

• Updated steps in Developing Locust docs to correctly invoke python, not pip3
• Updated Developing Locust docs to be more consistent

[cyberw]

Maybe this is no longer needed?

[mquinnfd]

We're still doing a poetry build in here, so it will build the front end otherwise, we could of course tie this to the matrix value, so that it's picked up by any future Windows workflows (hopefully this step is removed soon though if I can figure out the venv stuff on the runner)

[cyberw]

Ah, I thought SKIP_PRE_BUILD was already set here.

[cyberw]

Perhaps SKIP_PRE_BUILD: ${{ matrix.skip_pre_build }} would make more sense?

[andrewbaldwin44]

@mquinnfd I think we could skip the pre build for the "fail fast" test on Ubuntu as well right? Maybe to keep things consistent with the windows test and it would probably run faster?

[mquinnfd]

So...

Sort of!?

I found that building the front end (or not) actually does affect the fail-fast tests, I could probably find an example from earlier - some things give a totally different response code though (200 vs 500) so my current understanding is that the UI build is actually not optional for those tests currently 🤔

[andrewbaldwin44]

Ah I see and then I guess we just skip those tests if we're running on Windows

[cyberw]

What will happen if this is not present? Can we make it optional, just to make the install easier for people? (maybe not now)

[mquinnfd]

In terms of the plugin?

The default versioning will be used, which is not that big a deal really, we could omit this from this section of the docs if it's easier 👍

You'll just end up with something like 0.0.1dev1 or similar as the package version, not a deal breaker if you're just wanting to build a dev version of the project

What do you think?

[cyberw]

I'm thinking maybe using poetry ... instead of python -m poetry ... might help with readability in docs and GH actions?

Some people might have issues with poetry not having been placed in their path, but pip would/should warn them about that when poetry is installed...

Oh and same thing with pip3, just use pip. If someone still has pip pointing to pip2, well, that's just sad :)

[mquinnfd]

I'm thinking maybe using poetry ... instead of python -m poetry ... might help with readability in docs and GH actions?

Some people might have issues with poetry not having been placed in their path, but pip would/should warn them about that when poetry is installed...

Oh and same thing with pip3, just use pip. If someone still has pip pointing to pip2, well, that's just sad :)

Yeah to be fair, I think poetry want you to install this as a binary package, a bit like yarn or something else - we should be able to reduce that to poetry ... commands

We're basically doing the manual install listed here, mostly because I assume people will have access to pip and it avoids either running a shell script (and dealing with OS binaries) and it avoids depending on pipx (which is not in itself a bad idea)

[mquinnfd]

I'm thinking maybe using poetry ... instead of python -m poetry ... might help with readability in docs and GH actions?

Some people might have issues with poetry not having been placed in their path, but pip would/should warn them about that when poetry is installed...

Oh and same thing with pip3, just use pip. If someone still has pip pointing to pip2, well, that's just sad :)

We could also just link to the poetry install docs, as a prerequisite 🤔

[cyberw]

This is good enough for now I think. OK to merge?

[mquinnfd]

This is good enough for now I think. OK to merge?

I think it's definitely an improvement over what's in master currently, I have no problems with the merge as it stands, I'll raise some Issues for any straggling issues

[andrewbaldwin44]

Thanks so much for taking care of this @mquinnfd!