| name | playwright-java-release |
| description | Prepare a Playwright Java release after the rolling PR has merged — cut the release branch, mark the Maven version, draft the GitHub release, and tick the Java boxes in the internal checklist. |
Use this skill once the chore: roll driver to 1.X.0 PR has merged into main and the upstream JS v1.X.0 is published. The rolling work itself is covered by the [[playwright-roll]] skill.
Throughout this doc, replace X with the minor version (e.g. 60 for 1.60.0) and <user> with the fork owner (gh api user --jq .login).
The full release checklist lives in the private microsoft/playwright-internal repo as the v1.X checklist issue. Find its number once:
unset GITHUB_TOKEN
ISSUE=$(gh search issues --repo microsoft/playwright-internal "v1.X checklist" --json number --jq '.[0].number')
Tick each Java box incrementally (one PATCH per item) so the issue reflects accurate state if the flow is interrupted:
gh api repos/microsoft/playwright-internal/issues/$ISSUE --jq '.body' > /tmp/body.md
gh api repos/microsoft/playwright-internal/issues/$ISSUE -X PATCH --field body=@/tmp/body.md
1. Cut the release branch
Push release-1.X from current upstream/main (which now contains the merged roll commit):
git fetch upstream main
git push upstream upstream/main:refs/heads/release-1.X
2. Draft the GitHub release
Generate the release notes from the upstream docs:
cd ~/playwright
node utils/render_release_notes.mjs java 1.X > /tmp/v1.X.0-release-notes.md
The renderer leaves JS-isms that need fixing for Java. Apply these substitutions — the list is not exhaustive, eyeball the diff before publishing:
toMatchAriaSnapshot() → matchesAriaSnapshot()toHaveCSS() → hasCSS() (and other toHaveX matchers → hasX)browser.on('context') → browser.onContext()browserContext.on('download' | 'frameattached' | ...) → browserContext.onDownload() / onFrameAttached() / …
Create the draft directly against release-1.X — drafting against main and retargeting later is fragile because every gh release edit rotates the untagged-<hash> ID:
gh release create v1.X.0 --repo microsoft/playwright-java --draft \
--title "v1.X.0" --notes-file /tmp/v1.X.0-release-notes.md --target release-1.X
3. Bump the Maven version on the release branch
Cut mark-v-1.X.0 off upstream/release-1.X, run set_maven_version.sh, and PR back to the release branch:
git checkout -b mark-v-1.X.0 upstream/release-1.X
./scripts/set_maven_version.sh 1.X.0
git add -u
git commit -m "chore: mark 1.X.0"
git push -u origin mark-v-1.X.0
gh pr create --repo microsoft/playwright-java --head <user>:mark-v-1.X.0 --base release-1.X \
--title "chore: mark 1.X.0" \
--body "Updates Maven version in all modules to \`1.X.0\` for the v1.X release."
set_maven_version.sh only invokes mvn versions:set on pom.xml, tools/*/pom.xml, and examples/pom.xml, but the root invocation cascades through the reactor, so the expected diff is 11 poms: root + driver/ + driver-bundle/ + playwright/ (from the reactor cascade) + 6 under tools/ + examples/, all flipping 1.<prev>.0-SNAPSHOT → 1.X.0. Any other file in the diff is a red flag.
4. Publish
The user publishes the draft release manually once the mark-v-1.X.0 PR is merged. After publishing, CI pushes the artifacts to Maven Central and runs the Docker workflow automatically: https://github.com/microsoft/playwright-java/actions.
