fix(bin): stop repeat update reports and finish every watched tool's check - #6243
Closed
Craftora-ai wants to merge 6 commits into
Closed
Craftora-ai wants to merge 6 commits into
Craftora-ai wants to merge 6 commits into
Conversation
Carried unchanged from kunchenguid#3841 so the sweep rework that follows can build on its published source.
- Check every watched tool in its own concurrent worker, so a slow source no longer spends the budget of the tools after it; a tool still running shortly after the deadline is named as unfinished. - Remember reported findings by tool, source, and condition instead of their rendered text, so upstream commits, a newer release while an update is pending, and a sweep flipping between finished and unfinished are no longer news. - Keep an update's record when its source reached no answer, and hold check failures and unfinished sweeps for a day after they were last seen, so a flapping source is reported once. - Report an announcement command that exits non-zero without announcing anything as a check failure rather than as no update. - Add a per-tool probe_secs, and read npm installed versions from a folder's node_modules or a launcher's npx pin for packages outside PATH. - Lead the report line with the news, followed by what was already reported.
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…-tool-update-check.sh. The fifth (ci-3) already behaved correctly, so it only got a regression test. Each finding has one new behavioral test in tests/fm-tool-update-check.test.sh. The full suite passes (63 ok), and shellcheck and bin/fm-lint.sh are clean. Four of the new tests fail against the old script and pass now. The ci-3 test passes on both. - **ci-1 (a broken copy hid the published update):** when picking the newest installed copy, a copy whose version probe exited non-zero is now skipped. It still counts as the copy PATH resolves, so the existing test where a failing copy reports its version for PATH skew still passes. If no copy's probe succeeds and a published source is configured, the "exited N, so its version was not compared with the published release" failure is still reported. - **ci-2 (a commented-out pin was read as installed):** when reading a launcher's `npx` pin, lines whose first non-blank character is `#` are now skipped. The file read stays inside its time bound. - **ci-3 (sweep warnings repeating):** no code change. The test runs a malformed registry twice and a cut budget twice; each is reported once and the second run is silent. - **ci-4 (timed-out announcement read as an answer):** the timeout status is now checked before the output is matched. A timed-out announcement command is a check failure even if it printed a matching line first. A command that printed an announcement and exited non-zero without timing out still counts as reporting the update. - **ci-5 (one update listed twice):** the report line now shows one entry per finding key, using the first text found. Two sources reporting the same `<tool>/available` update give one line. One existing test had to change: `test_published_dedupe_and_composition`. Because of ci-5, a step expecting both the announcement text and the published text for the same key no longer holds. In that step the fixture now drops its announcement, so the published line still shows which installed copy was compared. The script header comment and docs/configuration.md are updated for ci-1, ci-2, ci-4 and ci-5
…er published release) in bin/fm-tool-update-check.sh. This round broke rule: when several sources report the same `<tool>/available` update, the report shows only the line naming the newest target version. How it works: the worker now tags each update line with the source that found it and the version that line names (`U <source> <version|-> <text>`). The announced version is used for announcements, the published version for releases, and none for git lines. collect_workers keeps one line per tool. A new helper, update_preferred, uses the existing version_newer to pick the newer version. If the versions tie, or one line names no version, the published line wins. Otherwise the first line found stays. Nothing changes in the key model or the retention rules. A partial install that leaves the tool behind is still the same single `<tool>/available` update, reported once and then deferred. I removed the old first-text dedupe in action_check. Each tool now gets exactly one available line, tool names must be unique, and no failure key is emitted twice, so that code could never run. I updated the header comment and the Repeat reporting section of docs/configuration.md to say which line is shown. Tests (tests/fm-tool-update-check.test.sh): - New test_an_older_announcement_does_not_hide_the_newer_release: the announcement names v1.78.0 and GitHub publishes v1.79.0. The report must show the "installed 1.75.2, published 1.79.0" line and not v1.78.0. It fails against the old script, which shows the v1.78.0 announcement, and passes now. - Changed test_one_update_found_by_two_sources_is_listed_once: it now expects the published line when the two versions tie, which this round's rule requires. It is still listed once. - Reworded one comment in test_published_dedupe_and_composition. Its assertions are unchanged. Verification: `shellcheck -x` on the script and the test file is clean, and bin/fm-lint.sh passes. I ran the full test suite once after the change. That run's output was cut to its last 15 lines, which were all "ok", including the new test, but I did not get a pass/fail count. A second full run to count results was still running when this phase ended, so I have not confirmed that every test in the suite passes
Author
|
Closing in favour of #5011, which addresses the same issue. |
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
2 participants
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.
Intent
bin/fm-tool-update-check.shkeys a reported update by its wording, so the same pending update is reported again whenever the upstream commit or release text changes.It also checks watched tools one after another under one time budget, so a slow source can leave the last tools unchecked.
Each pending update should be reported once, and every watched tool should get its check.
What Changed
probe_secs(1..30) can raise, and no probe runs past what the sweep has left. A tool still running at the deadline is reported ascheck incomplete: ... before <tool> finished.state/.tool-updatesremembers findings by identity, not wording. An available update is keyed by the tool alone, whichever source found it, so a newer commit or release while an update is pending is not reported again. A source that cannot answer keeps the recorded finding; the record is dropped once any update source for that tool answers "current". Check failures and unfinished sweeps are tracked separately and re-reported only after a day without them.publishedprobes read the npm registrylatestdist-tag or the latest GitHub releasetag_namewithcurland no credentials. The installed version comes from the tool's command, annpm_dirinstall or annpx_pinlauncher pin. When several sources report the same update, the line naming the newest version is shown.docs/configuration.md,docs/examples/watched-tools.jsonandtests/fm-tool-update-check.test.share updated.Testing
tests/fm-tool-update-check.test.shpassed (63 ok) before the last review-bot round; after that round the new regression test passes andshellcheck -xandbin/fm-lint.share clean.probe_secslets a slow binary answer;arm/ shim /disarmwork end to end.Pipeline
Updates from git push no-mistakes