fix(ci): dispatch camoufox template updates with camoufox's own Playwright version - #308
Merged
Merged
Conversation
…right version
The matrix already knows camoufox cannot use every Playwright release. It reads
the supported range from the package metadata and builds the camoufox image
with its own version list:
const imagePlaywrightVersions = isCamoufoxImage ? camoufoxPlaywrightVersions : latestFivePlaywrightVersions;
The dispatch to actor-templates then ignores that. It sends
`latestPlaywrightVersion` - the global latest - alongside a hardcoded image list
that includes camoufox. actor-templates writes that version into the camoufox
Dockerfiles, producing a `FROM` tag that was never built.
Today camoufox-js@0.12.0 declares `playwright-core: "<1.61.0"`, so the newest
camoufox image is 24-1.60.0 while the other images are at 24-1.63.0. The
dispatch claims 1.63.0 for all five. apify/actor-templates#872 is the result:
it pins apify/actor-node-playwright-camoufox:24-1.61.1, which does not exist on
Docker Hub, and its Docker build jobs fail.
Split the dispatch in two. The four regular images keep the existing version;
camoufox gets its own dispatch carrying `latestCamoufoxPlaywrightVersion`, which
was already computed one line away. The camoufox step is skipped when the matrix
resolved no supported version - the same condition under which no camoufox image
is built.
The Python playwright workflow had the identical defect and gets the same fix.
It happens to be harmless right now (camoufox==0.5.6 supports <1.63, and the
latest Python Playwright is 1.62.0, so both versions coincide) but it would
break the moment Playwright 1.63 reaches the Python images.
Verified by running both matrix scripts with GITHUB_OUTPUT set:
node:playwright latest-module-version=1.63.0
latest-camoufox-module-version=1.60.0
python:playwright latest-module-version=1.62.0
latest-camoufox-module-version=1.62.0
1.60.0 matches the newest camoufox tag actually on Docker Hub. Matrices with no
camoufox image (node:normal, node:puppeteer) emit no camoufox output, unchanged.
Typecheck clean, 23 tests pass, biome reports no formatting changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
github-actions
Bot
added
the
t-tooling
📦 Image size reportBuilt images compared against the currently published rolling tag for the same runtime version (e.g. Python basic images — 5 images (at 8220d9d)
Node basic images — 6 images (at 8220d9d)
Python + Selenium images — 5 images (at 8220d9d)
Node + Puppeteer images — 6 images (at 8220d9d)
Python + Playwright images — 25 images (at 8220d9d)
Node + Playwright images — 30 images (at 8220d9d)
|
vladfrangu
approved these changes
Sep 8, 2026
vladfrangu
left a comment
vladfrangu
left a comment
Member
There was a problem hiding this comment.
trim the comments in the yaml files and then merge, sorry and thank you!!
Condense the four-line comment above each camoufox dispatch step to a single line, per review feedback. No behavior change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TQJXEZ7g4H4fHv76J3hM5D
Member
Now that's a long name.
Any idea why the python images got ~3% bigger? Sidenote - the image size report is nice, but if you need to click though everything to find what you are looking for, it's far away from great. Can we analyze this and highlight if something got bigger or smaller, so we know we should pay attention and toggle those reports? |
Member
I feel like this is just run-to-run variance? Nothing else would explain it... (especially since this PR doesn't change py images) |
Member
|
Huh, I'd expect those numbers to be fully deterministic, what could cause that? Like some transitive deps changed? Not a blocker for sure, but those numbers should be deterministic, otherwise they are much less useful. |
Member
|
Yeah my gut says its either transitive deps or certificate changes that branch might be missing? To be fair, the size reporter is supposed to be useful when we do actual image file changes to see rough impact, not perfect.. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
TL;DR In actor-templates we are getting updates to non-existing camoufox images, this is a proposal for fix.
The defect
src/matrices/node/playwright.tsknows camoufox is special, and handles it carefully:The range is read from package metadata rather than pinned, and the image is dropped from the matrix entirely if it cannot be resolved — as
src/shared/camoufox.tsputs it, publishing a known-broken image is worse than publishing none.Then the dispatch discards all of it:
latestPlaywrightVersionis the global latest. It becomeslatest-module-version, which the workflow sends with a hardcoded five-image list, camoufox included.What it costs
camoufox-js@0.12.0declares:So the images diverge, correctly:
The dispatch claims 1.63.0 for both. apify/actor-templates#872 is what that produces — it pins
apify/actor-node-playwright-camoufox:24-1.61.1, Docker Hub returns 404 for that tag, and bothTest Docker buildsjobs fail while the other 53 checks pass. That PR cannot go green as written.The fix
Split the dispatch. The four regular images keep the existing version; camoufox gets its own, carrying
latestCamoufoxPlaywrightVersion.The camoufox step is skipped when the matrix resolved no supported version — the same condition under which no camoufox image is built, so the dispatch and the build stay in agreement.
The Python playwright workflow has the identical defect and gets the identical fix. It is harmless today by coincidence (
camoufox==0.5.6supports<1.63and the latest Python Playwright is 1.62.0, so the two versions match) but it breaks as soon as 1.63 reaches the Python images.Verification
Both matrix scripts run with
GITHUB_OUTPUTset to a temp file:1.60.0is exactly the newest camoufox tag on Docker Hub, and the node log line confirms the reasoning:Regression check on the matrices with no camoufox image —
node:normalemits onlylatest-runtime-version,node:puppeteeronly that pluslatest-module-version. Both unchanged.yarn typecheckclean,yarn test23/23 pass,yarn fmtreports no changes.Knock-on effects
Removing camoufox from the main image list changes the branch name actor-templates derives from it, so the existing
ci/apify/actor-node-playwright_..._camoufoxbranch is orphaned. #872 should be closed; the next dispatch opens two PRs in its place, one per image group.This also depends on apify/actor-templates#926, which fixes a separate crash in the receiving workflow. Until that merges, actor-templates cannot act on either dispatch.
Not addressed
Why camoufox-js caps at
<1.61.0is upstream and out of scope. actor-templates also still writes whatever tag it is told without checking it resolves — worth a guard there, but this PR removes the reason it currently gets told the wrong one.🤖 Generated with Claude Code