build(selenium-devtools-py): make the adapter fit to publish, and keep it that way

[vishnuv688]

What & why

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Polish (an improvement to an existing feature)
• Breaking change (existing behavior changes for users)
• Documentation
• Internal (build, CI, dependencies, tooling)

Packages touched

• shared (types and contracts)
• core (framework-agnostic capture/reporting)
• elements (published element/snapshot API — @wdio/elements)
• service (WebdriverIO adapter)
• nightwatch-devtools (Nightwatch adapter)
• selenium-devtools (Selenium adapter)
• selenium-devtools-py (Selenium Python adapter)
• backend (server)
• app (UI)
• script (page-injected runtime)
• trace (Trace mode)

Notes for reviewers

Screenshots / recordings

[greptile-apps]

Confidence Score: 2/5

The PR is not ready to merge because its release flow can omit a promised tag, strand a successful publish, or accept source changes without a version bump.

Findings

1.  First release skips its tag ▶
2.  Published release can remain unrecorded ▶
3.  Changelog edit bypasses version bump ▶
4.  Index errors appear as availability ▶
5.  Release workflow changes skip CI ▶

Summary

The PR adds shared Python package checks, a fragment-driven release process, a pinned-backend compatibility check, and publishing metadata and documentation.

• The first publish skips its promised tag when no fragments are pending.
• A concurrent update to main can leave an accepted PyPI upload unrecorded and difficult to retry.
• The fragment gate can permit later source changes without a releasable version bump.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  F[Pending fragments] --> A[Apply bump and changelog]
  A --> G[Check index and package]
  G --> P[Publish to PyPI]
  P --> C[Commit release state to main]
  C --> T[Push version tag]

Loading

_{Reviews (1) · Last reviewed commit: "ci(selenium-devtools-py): run the releas..."}

[greptile-apps]

First release skips its tag. On the first PyPI release, there are no pending fragments, so changes.py apply changes no files. This branch exits successfully after publishing but before creating or pushing py-v0.1.0, leaving the published version without the promised tag.

[greptile-apps]

Published release can remain unrecorded. If main advances while this job tests and publishes, this push rejects the release commit after PyPI has accepted the version. The version bump, changelog update and fragment deletions then remain off main; a rerun computes the same version and is refused by the index preflight. The concurrency group does not cover other writers to main.

[greptile-apps]

Changelog edit bypasses version bump. After the first release, a PR can change src/ and make any edit to CHANGELOG.md without adding a fragment. This check passes, but apply_release has no fragment to consume and does not bump the version. The source change cannot be included in a new PyPI upload until the release state is repaired.

[greptile-apps]

Index errors appear as availability. If the package index returns a 5xx response, this check treats it as proof that the version is free and continues toward publishing. The preflight has not established availability, so a duplicate version may be discovered only during upload.

[greptile-apps]

Release workflow changes skip CI. Neither path-filter list includes .github/workflows/python-release.yml. Changes confined to that workflow therefore do not trigger the Python CI checks, leaving release-only versioning, publishing and recording edits to be exercised for the first time during a release.