Skip to content

Facilitate reproducible Playwright runtime provisioning #75

Description

@omry

Motivation

Consumers that use Playwright currently need to select a prebuilt Playwright image or manually coordinate several coupled inputs:

  • the Python or Node Playwright package;
  • the browser revision compatible with that package;
  • native libraries required by the selected browser and base distribution;
  • the installed browser location and runtime environment; and
  • repeatable acquisition, caching, and offline materialization.

OmegaFlow exposed this gap while integrating its protected controlled-session controller. Its current draft uses mcr.microsoft.com/playwright/python:v1.61.0-noble, but that replaces the user-selected controller base merely to obtain a compatible browser runtime.

Reploy already carries related conformance machinery: .github/workflows/integration.yml downloads checksum-pinned Playwright fixtures, and the OmegaFlow controlled-session conformance profile uses a pinned browser controller base. This proves the need but is not yet a reusable blueprint capability.

Goal

Allow a Reploy application to request a reproducible Playwright runtime while retaining an ordinary compatible base image. Reploy should own the acquisition and materialization mechanics; the application should continue to own browser automation and its Playwright version constraint.

Candidate shapes

Evaluate the smallest public contract that satisfies the goal:

  1. Reusable package collection/profile: compose the Playwright binding, compatible browser payload, native packages, and runtime wiring from provider-owned package declarations.
  2. Dedicated tool:playwright capability: add a Playwright-aware tool/provider that derives or validates the browser revision, resolves its closed artifacts, requests native dependencies, and exports the executable/runtime coordinates.

Prefer existing provider primitives if they can preserve the invariants below without application-specific scripts or a hidden image substitution. Use a dedicated capability if compatibility resolution and browser artifact ownership cannot be modeled safely as an ordinary package collection.

Required behavior

  • Preserve the blueprint-selected base image rather than replacing it with a Playwright image.
  • Support an explicitly selected browser, initially Chromium.
  • Bind the browser revision to a compatible pinned Playwright binding version.
  • Resolve and retain browser downloads as verified, cacheable provider artifacts.
  • Materialize the final runtime without public network access.
  • Install the required native libraries through the supported OS provider for accepted base families.
  • Expose stable browser/runtime coordinates needed by the Playwright binding.
  • Run the application as its configured non-root runtime identity.
  • Fail early with actionable diagnostics for unsupported bindings, browser revisions, bases, platforms, or architectures.
  • Include all provider inputs in build identity and cache invalidation.

An initial Linux amd64 implementation is sufficient if unsupported targets fail explicitly. Linux arm64 support can be added when the upstream browser/binding combination is available and proven.

Non-goals

  • Browser actions, recording semantics, screenshots, or media compilation.
  • OmegaFlow-specific controlled-session behavior.
  • Arbitrary blueprint build hooks.
  • Implicitly selecting or changing an application base image.
  • Treating FFmpeg as part of Playwright unless a broader browser-media capability is deliberately designed.

Acceptance evidence

  • A blueprint using a normal supported Python or Node base requests Playwright plus Chromium without selecting a Playwright image.
  • Reploy resolves, builds, and then reuses the exact browser/runtime closure.
  • The built environment launches Chromium through Playwright and produces a deterministic smoke artifact with runtime public networking denied.
  • Repeated builds demonstrate cache reuse; incompatible versions and unsupported bases fail before deployment.
  • Provider, blueprint, CLI/help, and Linux Docker integration tests cover the chosen public contract.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions