feat(ci): add a playwright-1.63.0 tag #1

Merged

adibilisadmin merged 1 commit from feat/playwright-1.63 into main

2026-09-24 09:59:03 +00:00

adibilisadmin commented

2026-09-24 08:58:43 +00:00

Owner

Adds forge.cloud.adibilis.ch/platform/ci-images:playwright-1.63.0, the image core/core's e2e shards need for the @playwright/test 1.58.2 → 1.63.0 bump. Per this repo's pinning rule the image must exist before the consumer points at it, so this merges first; the consumer bump then lands in one commit (lockfile + container:).

Both playwright tags are built for the length of the upgrade. Until core/core's bump merges its shards still pull 1.58.2, and a shard whose image and lockfile disagree downloads a second browser set at runtime — exactly what pre-baking avoids. Once nothing references 1.58.2, drop that matrix entry; the published tag stays in the registry either way, it just stops being rebuilt.

The version is a PLAYWRIGHT_VERSION build arg, not a second copy of the Dockerfile, so two coexisting tags can't drift.

The playwright smoke test now asserts the baked version — it never did before. It checked only docker --version and curl --version, so a base-image bump that moved the Playwright version would have published silently under a tag promising the old one. It now greps the base image's own /ms-playwright/.docker-info:

grep -q '"driverVersion": "1.63.0"' /ms-playwright/.docker-info

npx playwright --version is unusable here: with nothing installed locally, npx downloads that version from npm and then reports what it just fetched, so it passes for whatever the image actually contains. I hit that while writing this and switched.

Verified locally (arm64, so the docker CLI layer differs from the runner's x86_64):

--build-arg PLAYWRIGHT_VERSION=1.63.0 builds; docker --version (29.8.1), curl --version and the version assertion all pass.
The same assertion against 1.58.2 correctly fails on that image.
--build-arg PLAYWRIGHT_VERSION=1.58.2 still builds and passes its own assertion, so the existing tag is unaffected.

Publishing needs no new secret — the workflow's existing REGISTRY_TOKEN covers both tags. It runs on push to main touching a *.Dockerfile or the workflow, which this PR does.

Adds `forge.cloud.adibilis.ch/platform/ci-images:playwright-1.63.0`, the image core/core's e2e shards need for the `@playwright/test` 1.58.2 → 1.63.0 bump. Per this repo's pinning rule the image must exist **before** the consumer points at it, so this merges first; the consumer bump then lands in one commit (lockfile + `container:`). **Both playwright tags are built for the length of the upgrade.** Until core/core's bump merges its shards still pull 1.58.2, and a shard whose image and lockfile disagree downloads a second browser set at runtime — exactly what pre-baking avoids. Once nothing references 1.58.2, drop that matrix entry; the published tag stays in the registry either way, it just stops being rebuilt. **The version is a `PLAYWRIGHT_VERSION` build arg**, not a second copy of the Dockerfile, so two coexisting tags can't drift. **The playwright smoke test now asserts the baked version — it never did before.** It checked only `docker --version` and `curl --version`, so a base-image bump that moved the Playwright version would have published silently under a tag promising the old one. It now greps the base image's own `/ms-playwright/.docker-info`: ``` grep -q '"driverVersion": "1.63.0"' /ms-playwright/.docker-info ``` `npx playwright --version` is unusable here: with nothing installed locally, npx *downloads* that version from npm and then reports what it just fetched, so it passes for whatever the image actually contains. I hit that while writing this and switched. **Verified locally** (arm64, so the docker CLI layer differs from the runner's x86_64): - `--build-arg PLAYWRIGHT_VERSION=1.63.0` builds; `docker --version` (29.8.1), `curl --version` and the version assertion all pass. - The same assertion against `1.58.2` correctly fails on that image. - `--build-arg PLAYWRIGHT_VERSION=1.58.2` still builds and passes its own assertion, so the existing tag is unaffected. Publishing needs no new secret — the workflow's existing `REGISTRY_TOKEN` covers both tags. It runs on push to `main` touching a `*.Dockerfile` or the workflow, which this PR does.

adibilisadmin added 1 commit

2026-09-24 08:58:43 +00:00

feat(ci): add a playwright-1.63.0 tag, built from a version build arg 4cb1a981a0

core/core is moving @playwright/test 1.58.2 -> 1.63.0, and per this repo's own
pinning rule the image has to exist before the consumer points at it. Both tags
are built for the length of that upgrade, so the e2e shards keep pulling the
version their lockfile matches until the bump merges.

The version becomes a PLAYWRIGHT_VERSION build arg rather than a second copy of
the Dockerfile, so the two tags cannot drift apart.

The playwright smoke test now asserts the baked version, which it never did
before — it checked only docker and curl, so a base-image bump that moved the
version would have published silently. It greps the base image's own
/ms-playwright/.docker-info; `npx playwright --version` is unusable for this,
because with nothing installed locally it downloads that version from npm and
then reports what it just fetched. Verified locally both ways: the 1.63.0 image
passes its assertion and fails a 1.58.2 one.

adibilisadmin referenced this pull request from a commit

2026-09-24 09:56:55 +00:00

build(deps): playwright 1.63.0, with re-recorded visual baselines

adibilisadmin merged commit c61bd09967 into main

2026-09-24 09:59:03 +00:00

adibilisadmin deleted branch feat/playwright-1.63

2026-09-24 09:59:03 +00:00

adibilisadmin referenced this pull request from a commit

2026-09-24 09:59:05 +00:00

Merge pull request 'feat(ci): add a playwright-1.63.0 tag' (#1) from feat/playwright-1.63 into main