Skip to content
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

[Feature]: Better support for CI and local development #502

Open
cedric-appdirect opened this issue Oct 22, 2024 · 3 comments
Open

[Feature]: Better support for CI and local development #502

cedric-appdirect opened this issue Oct 22, 2024 · 3 comments

Comments

@cedric-appdirect
Copy link

Does the upstream have similar features?
playwright-go is just a community-driven client for playwright. For feature requests, please refer to other officially supported clients first. Nodejs / Java / .Net / Python

Upstream doesn't have such feature, but implementing it in playwright-go might be easier due to the golang ecosystem.

Is your feature request related to a problem? Please describe.
When doing development with playwright-go and testing screenshot difference between CI (usually Linux) and local environment (usually Windows and MacOS). Solution to this is to setup a remote browser solution, but this create additional complexity. It is usually assumed that if things render in one OS, they will render close enough on any other OS.

Describe the solution you'd like
Automate the creation of a browser in a docker container locally and proxy all communication to enable local and CI tests to have the same result. I do have the code to do exactly that using testcontainer-go and goproxy, but before starting a PR, knowing if there is interest and how to shape it would be best.

Additional context
So how it work:

  • Create a http proxy on a random port using Go standard http server and goproxy
  • Wait for service to start
  • Create a container that will idle, but can run playwright node service and will have access to the proxy port
  • Exec node and serve browser using launchServer using a set of prefixed port to listen on and with the proper proxy setup (note that testcontainer-go does not allow HostAccessPort during the startup of the container, but they are only accessible during Exec).
  • Wait for the websocket port to start answering request
  • Use pw.Browser.Connect appropriately.

Overall it is maybe around 100 lines of code, but there is a lot of quirks to know about to get this working. It would be better if this is included in playwright-go directly.

Benefit, 100% pixels match between CI and local as they run in exactly the same environment.

@canstand
Copy link
Collaborator

canstand commented Oct 26, 2024

I prefer to do this in a new repo, since it doesn't matter whether the client is playwright-go or playwright-python.

And might it evolve into a community alternative to some of the features of the Playwright Testing Service?

@cedric-appdirect
Copy link
Author

I guess the Dockerfile and resulting image would be something that can be shared across language (There is just one requirement is that the version of playwright installed in the image as to match the one of the playwright-*), but the helper that does glue together playwright, testcontainer and a proxy logic will be per language I would think.

What do you think of one new repository for the image and one per language that implement the glue? Do you have any suggestion for the name? I think I can create a repository for the image that will be automatically kept up to date with github action and the go implementation (python is not my forte) and link them here.

@cedric-appdirect
Copy link
Author

I have put the beginning of such an idea here: https://github.com/cedric-appdirect/playwright-ci-go . Still need to write documentation, but would be interested to start getting some feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants