Skip to content

docs: update CLI and helm reference for v2.43.1 - #423

Merged
mbevc1 merged 1 commit into
mainfrom
reference-docs/v2.43.1
Sep 18, 2026
Merged

mbevc1 merged 1 commit into
mainfrom
reference-docs/v2.43.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Automated update of CLI and Helm reference documentation for release v2.43.1.

@mintlify

mintlify Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated
kosli 🟢 Ready View Preview Sep 18, 2026, 4:01 PM

@mbevc1
mbevc1 enabled auto-merge (squash) September 18, 2026 16:15
@claude

claude Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Claude encountered an error after 2m 59s —— View job


Doc review — v2.43.1 reference regeneration

  • Read doc-review skill and CLAUDE.md
  • Inspect the diff, separate real content changes from sample-data churn
  • Check overview.md (hand-authored) and version stamping
  • Cross-file checks: prose and sibling pages against the changed flag descriptions
  • Post findings

Of the 18 files, 14 (kosli_get_snapshot, kosli_log_environment, kosli_list_environments, kosli_list_snapshots, kosli_diff_snapshots, kosli_get_environment, kosli_list_flows) are pure regenerated sample-data churn — timestamps, snapshot indices, flow activity stamps; every changed line sits inside a JSON output block, no structure or key changed. overview.md is the expected v2.43.0v2.43.1 version stamp. The only substantive change is a new sentence appended to the shared -g, --commit flag description on 9 attest commands plus kosli begin trail, and begin trail's default changing from HEAD to unset.

The only internal link in the changed lines is /integrations/ci_cd, which resolves (integrations/ci_cd.md). I could not run gh pr checks in this environment, so link-rot status is unverified — per CLAUDE.md that check is unreliable anyway.

Upstream — does not block this merge

All findings below are on deterministically regenerated pages (kosli docs from the release binary). A hand-edit here is destroyed by the next release; the fix belongs in kosli-dev/cli.

1. client_reference/kosli_begin_trail.md:26 — the [defaulted] marker now contradicts the flag's own text.
The row reads [defaulted] The git commit from which the trail is begun. (defaulted in some CIs: ..., otherwise unset ). A flag that is unset outside CI is not defaulted. Compare kosli_attest_artifact.md:57, which still carries a real default and correctly shows (default "HEAD"). A reader scanning the [defaulted]/[optional]/[conditional] markers — which this reference uses consistently — will conclude begin trail still resolves a commit for them.
Fix in kosli-dev/clicmd/kosli/beginTrail.go: change the marker to [optional] (or [conditional]) to match the new behavior.

2. The new warning sentence never says what the reader loses.
On all 10 pages the sentence ends "a warning is printed and the attestation is sent without commit info". It stops one clause short of the consequence that matters. getting_started/attestations.md:76 states the match key for a pending attestation is (template artifact name, git commit) — so an attestation sent without commit info silently never binds to its artifact. A user who sees only a warning on stderr in CI has no way to connect it to an attestation that later appears unmatched.
Fix in kosli-dev/cli, in the shared attestation flag description (and beginTrail.go for the trail variant): add the consequence, e.g. "...and the attestation is sent without commit info, so it cannot be matched to an artifact by commit."

3. kosli_begin_trail.md:26 vs :37 — the two rows disagree about when --repo-root is read. Same pairing on all 9 attest pages.
The new --commit text describes what happens when "both --commit and --repo-root are left at their defaults and the commit cannot be read from the repository" — i.e. the CLI does try to read a commit from the working directory when --commit is unset. But the --repo-root row directly below says it is "Only used if --commit is used or defaulted in CI". If --commit is unset and you are not in CI, the second sentence says --repo-root is not used at all, and the first says its default is what the read is attempted from.
Fix in kosli-dev/cli: reconcile the --repo-root description with the new --commit behavior — one of the two is now stale.

4. Pre-existing, but this diff widens it: the four attest pullrequest siblings document --commit two incompatible ways.
kosli_attest_pullrequest_azure.md:37 uses the shared attestation description and picked up the new warning sentence in this PR. kosli_attest_pullrequest_github.md:35, ..._gitlab.md:35 and ..._bitbucket.md:41 still read only "the git merge commit to be checked for associated pull requests." — no CI defaulting, no [conditional] marker, no warning behavior. Those three pages are untouched by this PR, so the gap is upstream and predates it, but a GitHub user and an Azure user now read materially different contracts for the same flag.
Fix in kosli-dev/clicmd/kosli/attestPullRequestGithub.go, attestPullRequestGitlab.go, attestPullRequestBitbucket.go: adopt the shared description, or confirm the behavior really differs.


0 Critical, 0 blocking in this repo; 4 upstream findings (1 Improvement-level, 3 clarity). This PR is a faithful copy of upstream and is fine to merge.
· branch reference-docs/v2.43.1

@mbevc1
mbevc1 merged commit e61a505 into main Sep 18, 2026
5 of 6 checks passed
@mbevc1
mbevc1 deleted the reference-docs/v2.43.1 branch September 18, 2026 16:15

This branch was successfully deployed

1 active deployment
staging e0bfbd3a Deployed Sep 18, 2026 by mintlify[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant