Point a downloaded binary at the file that is beside it - #239
Merged
Conversation
The paragraph the runner prints at the end of `lab help`, `lab version` and the
unknown-verb branch named docs/privacy.md. That is where the file sits in a
checkout, and it is not what a download holds: the release publishes the three
documents flat, as separate assets beside the binaries, so somebody who took the
artefact route was sent into a directory that is not in front of them. Read off
the published release rather than off this tree:
gh api repos/Flowfin/lab/releases --jq '.[0].assets[].name' | grep -v '^lab_'
LICENSE
NOTICE.md
privacy.md
SHA256SUMS
SHA256SUMS.sig
THIRD-PARTY-NOTICES.md
One string still serves both routes rather than two strings drifting apart. Each
document now carries the two spellings it has - the path a checkout holds and the
name a download holds - and the paragraph names both. Two of the three are the
same word twice and only privacy.md is not, which is why a single spelling looked
right for as long as it did.
WHAT A CONTAINMENT TEST COULD NOT SEE IS THE REASON THIS DEFECT SHIPPED GREEN.
The two output tests asked strings.Contains for each document, and
"docs/privacy.md" contains "privacy.md", so the paragraph the issue was raised
against satisfied both of them for all three files. namesOnItsOwn splits the
output into the maximal runs of path bytes and compares whole tokens, so the
download spelling has to appear as a path of its own.
I proved that bites by putting the old paragraph back:
go test -count=1 -run NamesTheDocumentsAnOperatorIsOwed ./cmd/lab/
--- FAIL: TestHelpNamesTheDocumentsAnOperatorIsOwed
the help output does not name privacy.md as a path in its own right
--- FAIL: TestVersionNamesTheDocumentsAnOperatorIsOwed
the version output does not name privacy.md as a path in its own right
Two more guards hold the download spelling to what is actually published rather
than to an assumption about it. One asks that the name beside a binary is the
base of the path in the tree, and reddens on a mistyped spelling in the
declaration:
docs/privacy.md is published beside a binary as privacy.md, and this
declaration calls it docs-privacy.md
The other reads the release workflow, because the base above is only true while
that workflow copies the documents into the assets directory itself. It compares
the operands of that copy against the documents this package declares, and it
reddens in both directions - a document dropped from the release:
the release copies [LICENSE NOTICE.md] into the assets directory and this
package declares [LICENSE NOTICE.md docs/privacy.md]
and a copy that stopped being flat, destination "${assets}/docs/":
no line of the release workflow copies NOTICE.md into "${assets}/", so
nothing here publishes the documents beside the binaries
WHAT THAT SECOND GUARD CANNOT SEE is written beside it rather than only here. It
reads a workflow file and not a release, so it says what the next run of that
workflow would publish and nothing about what any published release contains.
And it finds the copy by shape, so an assemble step rewritten as a loop or split
across two commands reddens it while the documents still travel correctly.
The means is the Go this package is already written in, in the file that declares
the string, which fits because the rule is a property of that declaration and the
suite that judges it already exists. A check written anywhere else would need a
parallel apparatus to reach a constant in a command package.
The release workflow is unchanged. The repair is in the paragraph rather than in
the asset name, because a release asset name cannot carry a directory separator
and renaming the tree file would move the pointer every other document here uses.
Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.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.
Closes #235
What this changes
The paragraph the runner prints at the end of
lab help,lab versionand theunknown-verb branch named
docs/privacy.mdand nothing else. Each of the threedocuments now carries the two spellings it actually has - the path a checkout
holds and the name a download holds - and the paragraph names both:
It is still one string, printed by all three routes, rather than one per layout.
Two spellings that drift apart is the same failure the paragraph itself is
written against, one level up.
No path is removed from the tree. The two files this touches are
cmd/lab/main.goandcmd/lab/main_test.go, and the release workflow isunchanged: a release asset name cannot carry a directory separator, so the
repair is in the paragraph rather than in the asset name, and renaming the tree
file would move a pointer four other documents here use.
What failure it prevents
An operator holding a downloaded binary is told to read a file in a directory
that is not in front of them. The release publishes the three documents flat, as
separate assets beside the binaries, which is deliberate and is why the fix is
not the obvious one-word edit. Read off the published release rather than off
this tree:
Why this shipped green, which is the part worth reading. The two output
tests asked
strings.Containsfor each document, anddocs/privacy.mdcontainsprivacy.md, so the defective paragraph satisfied both of them for all threefiles. A test that cannot tell a paragraph naming both spellings from one naming
only the checkout spelling asserts nothing about the download route.
namesOnItsOwnsplits the output into the maximal runs of path bytes andcompares whole tokens instead, so the download spelling has to appear as a path
in its own right.
Two further guards hold that spelling to what is published rather than to an
assumption. One asks that the name beside a binary is the base of the path in
the tree. The other reads the release workflow, because that base is only true
while the workflow copies the documents into the assets directory itself, and it
compares the operands of that copy against the documents this package declares.
What was run
All of it at
e02958c0f50bd15e3567d1f92065d374e9bff6e8, the head being pushed,on Windows.
The guards, proved by breaking each one rather than by reading the code for it.
The old paragraph put back:
The download spelling mistyped in the declaration:
A document dropped from the release copy, and the same copy sent into a
subdirectory of the assets - both against the workflow, restored afterwards:
Then the gate, on the restored tree:
and the walk over this tree:
The integration-hardware harness was not asked for. That is the disclosure the
-vrun prints frominternal/hardware, and it is unchanged by this branch.The means. Go, in the package that already declares the string. The rule is
a property of that declaration, the suite that judges it is beside it, and a
check written anywhere else would need a parallel apparatus to reach a constant
in a command package. No language, runtime or dependency is added.
What this does not do
It does not read a release. The workflow guard reads
.github/workflows/release.yml, so it says what the next run of that workflowwould publish and nothing about what any published release contains. The
evidence above about the existing v0.1.0 assets is a reading of the tracker,
made by hand, and no test here repeats it.
It finds that copy by shape. An assemble step rewritten as a loop, or split
across two commands, reddens
TestTheReleaseCopiesTheDocumentsInFlatwhile thedocuments still travel correctly. That is a red gate asking for the test to be
rewritten against the new shape rather than a defect in the release, and the
comment on the test says so where somebody meeting the failure will read it.
It does not judge whether any of the three documents says what it should. That
is a reading of prose and no test here makes one, which is the bound the
existing tests already carried.
It adds no changelog entry.
CHANGELOG.mdcarries one entry per release and hasno unreleased section, and this is text a verb prints, which that file says is
not a contract and is announced there rather than anywhere else. The entry for
the release that carries this belongs to whoever cuts it; there is nothing in
this tree that will remind them, and that is a gap this branch does not close.
There is no second reader on this board tonight. Nothing here reached the
mainline that only its own author has read, in the sense the rule intends, and
this body carries the evidence in place of one rather than implying a review
that did not happen.