Repository navigation
Build the site against idfkit 1.0.0-rc.6 - #23
Merged
Merged
Conversation
The bump checks out idfkit-conformance into governance/ to read the consumer register, then stages everything, so the checkout lands as a gitlink at a3dddc36 with no .gitmodules entry beside it. Nothing on main has ever carried it and nothing reads it: the governance tag is pinned in pyproject.toml and fetched by scripts/_governance_source.py at build time. Merged as it stood, main would gain a submodule reference that resolves for nobody, and every later bump would carry it forward. Both open bump pull requests, #21 and #23, have it, which places the fault in the workflow rather than in either run.
Contributor
Author
|
Docs preview for this PR is available at: Changed pages: |
The strict build fails on 1.0.0-rc.6 with three warnings, all the same one: idfkit/geometry.py:628 documents translate_to_world by pointing at idfkit.scene.get_scene, and mkdocstrings cannot resolve a target on a module the site renders no page for. idfkit.scene ships publicly. get_scene, Scene, ResolvedSurface, SceneBounds and the rest are exported from the package root, and every other public module has a page under api/. This one was missed when geometry extraction landed, so the corrected resolution shipped to PyPI with its reference unreachable. Principle V requires the reference to be generated rather than written; here it was not generated at all. The page is the ordinary shape: a short description of what the module does and the mkdocstrings directive. The one thing it says beyond that is where the resolution came from, because a reader arriving at get_scene from translate_to_world is owed the reason the two now agree. Verified: the three autorefs warnings are gone. The local build still reports cairosvg failures, which are this machine having no cairo installed and not something this change touches; CI reported exactly the three warnings above and nothing else.
The gate failed the strict build with: Built site: 70,502,285 bytes, 0 WebAssembly file(s). hosts a 8,391,969-byte binary: search/search_index.json Both lines are from the same run. It found no WebAssembly and then reported a stray binary, which is the shape of a false positive rather than a finding. TEXT_SUFFIXES held html, js, css and mjs, so the search index counted as non-text and fell under LARGE_BINARY_BYTES once it passed 8 MB. mkdocs writes that file from every page's text, so its size measures how much documentation the site has. Adding a reference page for idfkit.scene was enough to cross the threshold, which means the gate was already within one page of firing on any change that added prose. The constant's own comment draws the right distinction and the suffix set did not implement it: the 28 MB generated HTML page is called out as "a real problem and a different one", and the search index is that same category. Engine bytes cannot hide behind this: BINARY_SUFFIXES catches .wasm and .wat at any size, and the size rule is a backstop for something arriving under another name, which JSON is not. Verified: the gate passes on the built site and still reports 0 WebAssembly files.
samuelduchesne
added a commit
that referenced
this pull request
Oct 14, 2026
The workflow checked idfkit-conformance out into governance/ and committed the whole tree, so the checkout became a gitlink with no .gitmodules entry. Merged, it breaks every checkout of main, as it did in idfkit-plugin (#23). The workflow itself is fixed separately.
samuelduchesne
added a commit
that referenced
this pull request
Oct 14, 2026
* chore: build the site against idfkit 1.0.0 * Remove the governance gitlink the bump workflow committed The workflow checked idfkit-conformance out into governance/ and committed the whole tree, so the checkout became a gitlink with no .gitmodules entry. Merged, it breaks every checkout of main, as it did in idfkit-plugin (#23). The workflow itself is fixed separately. --------- Co-authored-by: idfkit-bot[bot] <284417662+idfkit-bot[bot]@users.noreply.github.com> Co-authored-by: Samuel Letellier-Duchesne <sam@carbonsignal.com>
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
1 participant
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.
idfkit 1.0.0-rc.6 was released, so
[tool.idfkit.library]and the pinned dependency advance from1.0.0-rc.4.
Opened automatically by
notify-downstream.ymlin idfkit. Nobodyasked for it, which is the point: a release that renames a documented
interface makes pages wrong the moment it ships.
The checks on this pull request decide whether the pages survive
the new version. If they are red, a page describes something this
release no longer has under that name. Fix the page. Do not relax the
check, do not pin the level back, and do not merge past it.
Statements of unavailability this adoption closes
None.
The consumer register
Nothing to record: a bump changes nothing the register holds.