Explore using non-browser API/SSH based Workspaces E2E tests

MR: Pending

Description

Explore the ideas raised in this comment

@ealcantara Excellent points, and you are thinking outside of the box, as usual.

This comment especially made me think of new possibilities:

Can we test the lifecycle of creating, starting, and running, and terminating a Workspace using API-driven tests?

Given that a Workspace can be completely created via API, and also should be accessible via SSH, theoretically we could write a completely non-UI, non-Capybara-driven E2E test, which performs all manipulations/assertions via SSH.

Theoretically, this could also also include direct manipulation/assertion of VS Code itself, via the VS Code server APIs.

This idea is very appealing to me, because it completely eliminates the slowness/flakiness/maintenance overhead of Capybara-based browser tests, which was part of the pain I was hoping to reduce by moving to Playwright.

Of course we would still have some Capybara-based tests, but those would be minimal and mostly to exercise the happy-path of the GitLab webapp Workspaces UI behaviors, not the actual in-workspace behavior.

Acceptance criteria

TODO: Fill out (required)

• [Describe what must be achieved to complete this issue.]
• [If applicable, please provide design specifications for this feature/enhancement.]
• [If applicable, please list any technical requirements (performance, security, database, etc.)]

Implementation plan

TODO: Fill out or delete (optional)

[Provide a high-level plan for implementation of this issue, including relevant technical and/or design details.]