Revisit action handling

[asturur]

With recent speed gains in builds and prettier, we probably do not need to have the prime build action to download the cached fabricjs build for the run.
Starting an extra container to do that and upoload/download to cache seems an overkill for the infra.
Prettier - lint - typecheck can be probably chained now, with playwright being the one we are waiting for longer.

We need to make sure we do not start too many jobs/pods for the sake of extreme parallelization with no gains.

[asturur]

Maybe moving playwright on its own action is enough now that we are not trying to mix coverage of all testing together.

[Smrtnyk]

i would also experiment by disabling coverage capture in playwright tests
maybe it will make them faster in execution
worth a try I guess

[asturur]

We do not need coverage from playwright anymore, because we can also focus just on unit test coverage and call it a day.
It is also easier to understand what you can expect coverage from and what the coverage looks like.
End to end test often cover a lot of stuff as a side effect but do not necessarily validate it

[Smrtnyk]

with playwright being the one we are waiting for longer.

well playwright now takes 2 minutes, firefox vitest takes similar times
i will look at few playwright tests that have high execution times to see if there is room for improvement

for me locally playwright tests take 18s now

and i am running them just with half available workers they could be much faster in CI if Ci would give a bit better machine

but 2 minutes on e2e in CI is still great progress we did

[asturur]

i think an improvement would be to divide the long visual rendering test that is a single test with 200 steps in more tests. like one per folder if it makes sense. I suspect that is one issue, but i didn't verify

[Smrtnyk]

i think an improvement would be to divide the long visual rendering test that is a single test with 200 steps in more tests. like one per folder if it makes sense. I suspect that is one issue, but i didn't verify

Given that I heavily work with playwright at work for 5 years now, my opinion is that it is not an issue, because we are running playwright with "fullyParallel" flag, it means even tests in the same file are run in parallel.
This is where playwright is different from jest and vitest, it is capable to run all tests truly parallel even in the same file.

Problem is that CI is constrained to just a few workers so it can only run just a few tests in parallel.

If you look at the test timings they all run pretty fast, except few of them that operate on the big svgs and image files applying expensive logic and take like 10s.
I do not dare to touch those tests, but I did find 1 where there is an artificial delay on keypress, not sure why that delay was added but will try to see if there is a room for improvement.

Other than that, I don't think you can squeeze more.
We reduced from 5min to 2min by adjusting config and removing coverage.
Locally they run in 18 seconds for me which is pretty fast.
What is left is to optimize few slower tests as seen in timings, and maybe see if github offers more decent machines for OSS projects.

Now, this is just my opinion based on experience and analysis I did, and could be wrong