feat!: add generic e2e support to check-store workflow

[digitalrisedorset]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/graycoreio/github-actions-magento2/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

check-store.yaml currently supports:

• coding-standard
• unit-test
• smoke-test

There is currently no generic mechanism for executing optional store-defined E2E test suites within the reusable workflow.

Fixes: N/A

What is the new behavior?

Adds optional e2e-test support to check-store.yaml.

The workflow now:

• provisions a Node runtime
• installs npm dependencies when a package.json exists
• executes npm run test:e2e

This keeps E2E implementation details owned by the consuming store while allowing Mage-OS CI orchestration to execute generic Node-based E2E suites.

A minimal TypeScript-based E2E fixture was also added to validate the orchestration flow.

Does this PR introduce a breaking change?

• Yes
• No

Other information

This intentionally keeps the E2E contract lightweight and framework-agnostic for now.

The workflow orchestrates execution but does not enforce:

• Playwright
• Cypress
• browser-specific tooling
• E2E file structure conventions

This allows consuming stores to define their own E2E implementation details while reusing the existing Mage-OS orchestration and Magento service bootstrapping.

[damienwebdev]

@herve

So, what I'd like to see is that we can run this against a store even if that store doesn't have the e2e tests installed.

So detect-e2e currently gates this against running if one isn't found, let's actually install the sample data and the e2e tests and attempt to run them.

[digitalrisedorset]

@herve

So, what I'd like to see is that we can run this against a store even if that store doesn't have the e2e tests installed.

So detect-e2e currently gates this against running if one isn't found, let's actually install the sample data and the e2e tests and attempt to run them.

@damienwebdev I've pushed a follow-up commit.

The workflow now:

• Continues normally when no E2E suite is present.
• Installs sample data when E2E is enabled.
• Installs the MageOS-adapted Playwright suite.
• Executes the Playwright tests.
• Removes the Node version pin.

I think this gets us much closer to the flow we discussed earlier today. Could you take another look when you have a moment? I suspect these changes might need tuning from where we are but this structure should be what we are aiming at. Once it works, I'll start 2 new activties:

• adding more Playwrights test on a weekly basis to start adding genuine tests coverage (this is something anyone can add to as well)
• start a E2E adapter so that any E2E tests suite can work. Lucas might want to join to add his test suite to work as an alternative

[digitalrisedorset]

@damienwebdev I've removed the guards you mentioned. I understand this is so that we can discover fully the E2E execution path and identify what still needs to be wired up. I imagine we may reinstate some of these guards once E2E tests are fully integrated.