Skip to content

Conversation

@cgraham-rs
Copy link
Collaborator

@cgraham-rs cgraham-rs commented Sep 3, 2025

Intent

Add initial e2e support and test for Publisher deployments on Posit Workbench using Positron.

Fixes #2911

Type of Change

    • Bug Fix
    • New Feature
    • Breaking Change
    • Documentation
    • Refactor
    • Tooling

Approach

  • Leverage previous work that implemented manual Workbench testings in chore(workbench): enable Posit Workbench for local manual testing #2909
  • Leverage existing VS Code commands and workflows as much as possible
  • Enabled the following plugins:
  • Add new Workbench-specific commands to a new workbench support file and name them as clearly as possible to reduce potential confusion
  • Added some new commands to CI to save Workbench related logs as artifacts which deviates from the current method of printing them to the CLI
  • Also deviated from the existing method of post-test DEBUG where we print out the installed extensions, etc. as most of that is captured during the Workbench extensions install command
  • In order to ensure a clean Workbench environment for each test leverage our justfile commands to stop, remove, and start a fresh Workbench container. This adds approximately 25 seconds to each test but is the only way I could find that would ensure a completely clean environment
    • Will create a ticket for future work that can try maintaining test isolation by creating new users for each test, though this may be challenging since we're using the public Workbench container
  • Implement the following tests leveraged directly from test/e2e/tests/deployments.cy.js:
    • static deployment test that I used to get us started and prove that all of this works locally and in CI
  • Updated CONTRIBUTING for all of the Workbench related changes in this and the previous PR

KNOWN ISSUES

  • The first test that runs, does the first visit to Workbench, then silently errors and restarts, then works fine after.
    • I've chased this down to overriding the baseUrl in the spec, which is a valid thing to do. But when the baseUrl in Cypress config does not match when we do our first visit() Cypress silently restarts the whole spec again. If they do match this restart is not observed. Publisher is currently using an older Cypress version so maybe a version upgrade would correct this behavior, though I see nothing obvious mentioned in the Cypress changelog. We do have a paid contract with Cypress and they are responsive if we can provide a reproducible issue.
  • Positron session is successfully started though it takes ~60s. This seems related to running Workbench in Cypress as the Positron sessions start quickly in my local browser from the same Workbench container. This occurs when running via Cypress locally or in CI.

User Impact

None

Automated Tests

New Workbench-specific Cypress e2e spec.

Directions for Reviewers

  • Follow the existing local just dev workflow and ensure you can run the Workbench spec
  • Verify the Workbench spec ran and passed in CI
  • Verify the new Workbench-specific command names make sense and are clear without having to dive deeply into the code

Checklist

@cgraham-rs cgraham-rs force-pushed the cgraham/e2e-workbench-positron-cypress branch from b998480 to e737281 Compare September 3, 2025 16:13
@cgraham-rs cgraham-rs force-pushed the cgraham/e2e-workbench-positron-cypress branch 2 times, most recently from 2394956 to 572f95f Compare September 15, 2025 14:49
@cgraham-rs cgraham-rs force-pushed the cgraham/e2e-workbench-positron-cypress branch 2 times, most recently from 374ae2c to 643d9f1 Compare September 26, 2025 17:53
@cgraham-rs cgraham-rs force-pushed the cgraham/e2e-workbench-positron-cypress branch from 643d9f1 to 3cbb1c2 Compare November 21, 2025 17:59
cypress:
name: e2e tests (cypress)
runs-on: ubuntu-latest
runs-on: ubuntu-latest-8x
Copy link
Collaborator Author

@cgraham-rs cgraham-rs Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong notes indicating why this change was made, but minimally to get Workbench to start quicker. We can explore reducing this to a 4x runner or back down to the standard runner, and remove any related container debug output.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed it might be worth a try to drop it down and see how it does (or if there's any negative impact).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests run fine with the standard runner, though slightly slower. Will leave it at standard so we are not needlessly consuming the larger runners.

Runner E2E Job Time Difference
ubuntu-latest-8x (8 cores) ~11m 38s Baseline
ubuntu-latest (2 cores) ~13m 14s +1m 36s slower (+13.7%)

Copy link
Collaborator Author

@cgraham-rs cgraham-rs Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And finally discovered one likely reason the 8x runner was chosen.

failed to register layer: write /usr/lib/rstudio-server/bin/quarto/share/deno_std/cache/gen/https/jsr.io/766911eda918ff2de41436f0cd1bd07e1f75dc019f40fdb27f776b8d6c7b3239.js: no space left on device

Have added a script we use in other repos that can tidy the runners to ensure adequate disk space without requiring a larger runner.

Before
Used: 54G/72G (75% full)
After
Used: 38G/72G (53% full)

@cgraham-rs
Copy link
Collaborator Author

Current failure with the Workbench test.
image

@cgraham-rs
Copy link
Collaborator Author

Current failure with the Workbench test.

And finally fixed with some retooling of setting permissions for the rstudio Workbench user with the content-workspace folder

@cgraham-rs cgraham-rs requested a review from tyatposit December 2, 2025 21:33
@cgraham-rs cgraham-rs marked this pull request as ready for review December 2, 2025 21:39
Copy link
Collaborator

@tyatposit tyatposit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit of a rough session startup time length, but overall looks good to me and passing locally. Just 1 issue i ran into building and that possible issue with clicking the input box selection. Plus a few minor suggestions.

cypress:
name: e2e tests (cypress)
runs-on: ubuntu-latest
runs-on: ubuntu-latest-8x
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed it might be worth a try to drop it down and see how it does (or if there's any negative impact).

cy.log("Installing Publisher extension in Workbench");
cy.exec(`just install-workbench-extension release`, {
failOnNonZeroExit: false,
timeout: 30_000,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: could potentially extract these out into variables with naming that helps explain the need for the waits. might also help with future updates if that ever happens though i think this is the only timeout that is repeated. 🤷‍♂️

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timeout: 30_000 is repeated three times in this file but they're used for very different functions so I'm not confident the same value will continue to be identical in all cases forever.

cy.log("Starting Workbench Positron session");

// Start a Positron session
// TODO remove this workaround for "All types of sessions are disabled" error after Workbench 2025.12.0 is released
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there's a gh issue tracking this, would be helpful to link it here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have guidance for adding links to private repos here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point with this being a public project. I wasn't thinking about that. maybe a question for @jonkeane ?


/**
* Checks if an interpreter is ready without attempting to start one
* @returns {Cypress.Chainable<boolean>} - Returns a chainable boolean indicating if interpreter is ready
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

liking these @returns
good idea and nice to have. 👍

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

Successfully merging this pull request may close these issues.

Get the Workbench container in CI and execute e2e tests against it

3 participants