[build] Fix the two CDDL repin fallouts breaking every Python target - #18068
Merged
Merged
Conversation
The webref repin renamed the Web Bluetooth extract to bluetooth-scanning, and MODULE.bazel followed, but py/BUILD.bazel kept the old repository name. Every Python target that reaches //py:create-bidi-src now fails analysis with "No repository visible as '@web_bluetooth_all_cddl'".
.gitattributes normalizes by content, so a Windows checkout gives the overlays in common/bidi CRLF endings. The CDDL parser keeps the carriage return in the production name, so every type those files define becomes unresolvable and BiDi schema generation fails with "unresolved type mozDebugging.GetScriptSourceParameters" and the like. Converting the overlays to CRLF reproduces the same failure on a POSIX host.
3 tasks
diemol
approved these changes
Sep 23, 2026
diemol
left a comment
Member
There was a problem hiding this comment.
Oh, nice. This will fix CI, thanks!
Member
|
Just for documentation.... The commit referenced above was to remove the workarounds in place that were no longer needed after w3c/reffy#2167 & w3c/reffy#2166 were merged. It just happened at the same time as Bluetooth spec changed the location of its cddl. That commit was supposed to make it so everything would pass as soon as w3c/webdriver-bidi#1166 merged, but I forgot that Python is also still generating code from the hard coded list. So this is a good fix for that, and hopefully we can move off of this generated code soon. |
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
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.
🔗 Related Issues
No issue; this is fallout from
c27beca214([build] repin webref CDDL and drop the reffy CDDL header workaround). Split out of #17970, which cannot be verified on any platform without it.💥 What does this PR do?
Two independent one-line build fixes. Every Python Bazel target on
trunkcurrently fails, andcreate-bidi-src_schemafails on Windows.1.
py/BUILD.bazelstill names the old Bluetooth CDDL repository. The repin renamedweb_bluetooth_all_cddltobluetooth_scanning_all_cddlinMODULE.bazelandcommon/webref_cddl.bzl, butpy/BUILD.bazelkept the old name, so anything reaching//py:create-bidi-srcfails analysis:This is already failing on
trunk— seePython / windows-smokeand the other ~20 Python jobs in the CI run forc27beca214. It has stayed unnoticed since because the two commits that landed after it touch Java and .NET, and the Python jobs are file-scoped, so they have not run again.2. A Windows checkout gives the CDDL overlays CRLF endings.
.gitattributesnormalizes by content (* text=auto) and has no rule for*.cddl, socore.autocrlfrewrites the five overlay files incommon/bidi/. The CDDL parser keeps the carriage return inside the production name, so every type those files define becomes unresolvable and schema generation fails:Those four namespaces are exactly the four checked-in overlays —
Debugging.cddl,Profiler.cddl,digital-credentials-command.cddlandweb-bluetooth-events.cddl. Nothing downloaded from webref is affected, becausehttp_fileis not subject to.gitattributes.🔧 Implementation Notes
I checked the second one rather than inferring it: converting
common/bidi/*.cddlto CRLF on macOS and rebuilding//javascript/selenium-webdriver:create-bidi-src_schemareproduces the Windows failure exactly, including thedropped from schema:lines. Reverting the line endings makes it pass again.The fix is
*.cddl text eol=lf, alongside the existing entries for*.java,*.html,*.cssand*.js. Normalizing in the generator instead would work, but the rest of the repo already solves this at checkout time, and doing it here keeps every consumer of these files — not just the JS generator — safe.The two fixes are separate commits so either can be dropped independently.
🤖 AI assistance
💡 Additional Considerations
//py:create-bidi-src,//py:bidi_protocol,//javascript/selenium-webdriver:create-bidi-src_schemaand//py:unit(32/32) all build and pass on this branch;//:buildifierleavespy/BUILD.bazelunchanged. The.gitattributeschange cannot be exercised on a POSIX host, so CI's Windows jobs are the real test — they are green on the equivalent commits in #17970, wherePython / windows-smokewent from failing to passing.Worth considering as follow-up:
scripts/update_cddl.pyrenames repositories when webref does, so it would be worth having it check for stale references outsidecommon/webref_cddl.bzl, or having the merge step reject a production name containing whitespace so a line-ending problem fails with a clear message rather than as an unresolved type.🔄 Types of changes