Feat/piace implementation - #3
Merged
Merged
Conversation
The three formats now show the same document at three levels of detail, decided through shared helpers so they cannot drift apart in what a value says. JSON is unchanged: it stays the complete machine-readable record and takes no display options. HTML keeps everything too and uses disclosure instead of omission. Edge changes, aggregate edge groups, an estimate's PQL, request options and full certname list are all on the page inside closed <details>; a target's resource changes open by default. The page is redesigned around a light palette on a warm paper ground, a serif/sans/mono split so identities and values are distinguishable without color, a colored +/-/~ gutter, sticky section headers, and a masthead tally. Requirement 8.3 rules out webfonts and image files as well as CDNs, so the type is system font stacks with declared fallbacks and the disclosure marker is drawn in CSS. Text is the only format that omits, because a CI log is a linear read with nothing to expand. It drops edge changes -- a consequence of the resource changes, and routinely more numerous -- along with each estimate's query mechanics, and caps an estimate's certname sample. The new --impact-nodes flag lifts that cap; it is a text-report control and leaves the HTML artifact byte-identical. On a real four-target run this takes the text report from 3623 to 1297 lines and the HTML reading path down by 59%. Requirements 5.3, 6.5, 7.4, 8.2 and 9.4 are discharged by the JSON report, and visibly by HTML as well; acceptance tests assert them there rather than in stdout. Two invariants keep the trimming honest: every section header counts what it actually displays, and a target whose only differences are edges is never rendered as unchanged -- HTML shows the edges, text prints a note -- so no report reads as "nothing changed" on a run that exits non-zero. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every list of rows -- resource changes, edge changes, aggregate groups, exclusion detail, provenance, and an estimate's PQL, request options and node list -- now sits in a closed <details> whose summary carries its count, so the page a reader lands on is the outcome, the reasons, the tally, and one line per target with a counted chip per section. What stays outside every disclosure is what requirements.md 8.5 requires visibly marked: retrieval and compilation failures, the v3 warning, the run diagnostics and the outcome badges. A mark a reader has to go looking for is not a visible one. A failed impact estimate would be invisible inside the closed estimate list, so its count rides on that summary rather than lifting the entry out of its place. Nothing is capped and nothing is dropped: a closed disclosure already keeps a thousand certnames out of the reading path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A `v*` tag now runs the test matrix, builds every platform, and publishes a Release from the artifacts the build job already verified -- manifest checked, static linking confirmed, version stamp asserted -- rather than rebuilding bytes nothing has checked. A malformed tag fails before anything is built; a `-suffix` version publishes as a prerelease. `contents: write` is raised locally in the release job rather than at the workflow level, where it would also be handed to the test job that runs the code under review. Tag runs are never cancelled by concurrency: a published tag with no release is worse than a superseded run. The detached signature stays manual -- CI holds no signing key -- so the generated notes say plainly that the checksums show a download is intact, never where it came from, and docs/release.md carries the signing step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two sources of false or misleading output, both found against a deployed OpenVox installation. A File resource with `ensure => directory` or `recurse => true` names a directory tree, which the compiler's file_content endpoint cannot serve: it answers HTTP 500 with an empty body, for both the trailing-slash and the bare form. PIACE attempted retrieval anyway whenever such a resource's `source` changed, then reported the inevitable failure as content_indeterminate -- an error-severity verify_content diagnostic turning the whole target into an operational error, exit 30 -- as if content evidence had been lost, when byte-level evidence was never the right evidence for the resource. Resolution now stops between step 2 and step 3 for those resources: a changed reference is reported as reference_changed with a *warning*, so the fact is still recorded and no digest is claimed, but nothing failed and the outcome does not say it did. An unchanged reference with some other content-bearing parameter changed stays content_indeterminate. The predicate keys off `ensure` and `recurse`, never the trailing slash, which was present on only one side of the case that surfaced this. Separately, the PuppetDB terminus injects an `alias` parameter into a stored catalog for every resource whose namevar differs from its title. A compiler's own catalog carries none, through either v3 or v4, so comparing a PuppetDB baseline against a compiled candidate reported a spurious `alias: [...] -> null` for 9 of 53 resources on one measured node -- and `alias` was the only parameter present on one side and absent on the other. It is generated catalog metadata under requirements.md 5.9, and dropping it cannot hide a real difference: it only registers extra keys in the compiler's resource index and is never enforced on a node. The drop is symmetric, because a file baseline captured from PuppetDB carries it too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The README said PIACE does not "write anything to PuppetDB". That is true
of PIACE itself -- every PuppetDB request it makes is a read -- but not of
a run: on `catalog_api: v3` the compiler stores the facts submitted and
the catalog it compiled, because that endpoint has no persistence control.
The v4 path changes nothing, carrying `persistence: {facts: false,
catalog: false}`. The section documenting this was already accurate; only
the blanket sentence in the intro contradicted it.
Adds a subsection spelling out the one workable v3 arrangement: a
baseline captured to a file, which the candidate compilation cannot reach
in to overwrite, produced by `piace capture catalog` at the same path
`compare` later reads. It also records that config validation does not
yet enforce requirements.md 1.8 -- `catalog_api: v3` with
`baseline.source: puppetdb` loads, runs, and corrupts the baseline it just
read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.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
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.
No description provided.