-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: editor e2e #378
feat: editor e2e #378
Conversation
Changed Files
|
|
We should document somewhere that we need to run |
And also that |
export const disablePlausible = async (page: Page) => { | ||
//disable plausible | ||
await page.evaluate( | ||
async () => await window.localStorage.setItem("plausible_ignore", "true"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice and simple
@@ -1,9 +1,10 @@ | |||
import { test, expect } from "@playwright/test"; | |||
import { testText, defaultBeforeEach } from "../test-commands"; | |||
import { testText, disablePlausible } from "../test-commands"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks for adding this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready to merge, except for the top-level README.md documenting how to run these tests.
It is part of the husky/post-install process. Should I make it post-checkout instead? |
5cd5d9c
to
9614658
Compare
The updated readme looks nice, thanks! |
b7a86ab
to
8fb71e5
Compare
Post install seems like the right time, as long as it's also documented (as you now did) because if I update an existing sandbox where I did the install before this was added, then I won't have done it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The looks good to me.
The only thing I disagree with is going to 9 shards: we spend about 3 minutes in each shard setting up (install, spin up, etc), and in each shard we do at most 1 minute of work. It just feels like wasted resources. I would go back to 4 shards, maybe even 3, to keep the ratio of setup to work more reasonable. I know this will mean waiting a couple minutes longer for CI to finish, but I don't like all those CI minutes just spent installing.
Is it possible to have multiple threads in the same shard?
According to https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories the standard runner has 4 CPUs, so maybe it's possible to have just one job doing all the installation just once, and have 4 separate processes in the same job doing all the shards?
Yes, I believe it is. I just tested and this works in CI:
Replace the |
Oh, wait, playwriting accepts a |
8fb71e5
to
1813969
Compare
I have reduced the shards to 3 and increased the workers to 4. |
PR Goal?
Add tests for the studio editor
Fixes?
n/a
Feedback sought?
readiness check
Priority?
high
Tests added?
How to test?
npx nx run-many --targets=serve,serve-fr,serve-es --projects=studio-web
in the local branchnpx nx e2e studio-web
Test notes
Confidence?
high
Version change?
no, all changes are to support end-to-end testing