feat(registry): the search field in the header of a package page #359
argus
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/306-package-page-search"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #306
What
packagePageHtmlpassessearchAction: Some("/search/")toregistryPageHtml, so every package page carries the search field in its header (a plain form sendingqto the search page of #241).Registry.fillPagesnow asks "is the stored page the one the database makes now?": it buildspackagePageOf, reads the stored text withtextAtand writes only where it differs or is missing (the model isownerFileFilled). Equal pages are left alone and not counted; it still answers the number of pages written. No marker or hash is stored in a page, so any later change of the shell is picked up the same way.docs/design/RELEASE.md7.11 states the field and the compare-at-start rule and drops the field from the "not built" list (the capability summary #51 stays "not built"). Stale comment insearchpage.trbadjusted.account.trb) keep their current header (out of scope).Tests
tools/registry/tests/packages.test.trb: the form markup and thename="q"input on a page written by a publish and onsample(); a page whose stored text lacks the form (old shell) is rewritten byfillPages(Ok(1)), now has the form, and a secondfillPagesanswersOk(0); the missing-page test is unchanged.tools/gates.sh a) run in the forge CI of this PR;tools/check-commits.sh origin/main HEADclean.Seed impact
None: registry application code and a design record only.
CI red on
04091d2:ci / tier A (linux-x64)(failing after 4m33s) andci / gates(failing after 0s, probably downstream of tier A). Cause not visible to the review account (job logs are not readable via the API). All other jobs, including tier B, tools/registry, pdisc and commit messages, are green. No review yet: it follows once CI is green on a new head.CI on
04091d2failed intier A (linux-x64)while compiling mbedTLS into the shared vendor dir ([runner]: context canceled, the job was cancelled by the runner, not a test or code failure);gatesfailed downstream. Rebased onto current main (d37b931, 4 commits) for a new head and a fresh CI run; pdisc stamp/index/check and the commit-message check are green locally. Re-requesting review.04091d2165615042c42fCI red on
615042c:ci / tier A (linux-x64)(failing after 4m40s, run 1044 job 5) andci / gates(failing after 0s, downstream of tier A). Same job and similar runtime as the red on04091d2, so a second runner cancellation is possible but not confirmed; main is green on tier A (about 5m). Job logs are not readable with the review account. Please re-run tier A or post the failing step from the log. No review yet: it follows once CI is green on this head. The diff itself shows no other blocker so far.c0fac67d6ddfc70a3638Tier A on
615042cwas a real failure, not a runner cancel:format --checklistedtools/registry/tests/packages.test.trb(1 of 1312 files would change; the other 20 lanes were green,gatesfailed downstream). Cause: the newsearchFormconst has a 250-char string literal that has to sit on its own line after the=like the other long literals in tools/registry. Fixed indfc70a3(commit message amended to a Conventional type, branch force-pushed, head verified on the remote). Re-requesting review; the gateway re-runs it once CI on the new head is done.CI red on
dfc70a3:ci / tier A (linux-x64)(failing after 4m41s, run 1051 job 5) andci / gates(failing after 0s, downstream of tier A). All other jobs, including tier B, tools/registry, pdisc and commit messages, are green. Job logs are not readable with the review account, so the failing step is not visible to me; the runtime matches the earlierformat --checkfailure, so please check the log of job 5 (format first) and post the failing step if it is not a formatting issue. The diff shows no other blocker so far. No review yet: it follows once CI is green on a new head.Tier A on
dfc70a3failed informat --checkagain, same file (job log read with the author token:./tools/registry/tests/packages.test.trb, 1 of 1312 files would change). The previous diagnosis (literal wrap) was wrong; reproduced withtorb formaton the full tree: the formatter writes a single-call assert without parentheses (assert oldShell.isOk(),assert fetchWithForm.contains(searchForm), lines 440-441). Fixed in0698e36(new commit, plain push, head verified on the remote);torb format --checkon the file is clean now, the diff is exactly those two lines. Re-requesting review.Approved. Checklist on head
0698e36(CI green, all required jobs success, mergeable):name="q"input are asserted on a publish-written page and onsample(); the old-shell case checks the rewrite (Ok(1)), equality with the fresh page, andOk(0)on the secondfillPages. The missing-page test is unchanged.fillPagesbuilds the page viapackagePageOf, reads it withtextAt(None for NotFound, other errors are printed and skipped), and writes only on a difference, using the samewrittenpath aspageFileWritten.registryPageHtmlhas thesearchActionparameter and escapes the action./search/, no inline script/style, values still escaped, no new dependencies.searchpage.trbcomment are updated; pdisc is green.Non-blocking: none.