@3f-consulting/spec-controller-core 0.1.0-alpha.7 → 0.1.0-alpha.71
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +3 -3
- package/dist/assemble/evidenceReconciliationFromSources.d.ts +5 -40
- package/dist/assemble/evidenceReconciliationFromSources.d.ts.map +1 -1
- package/dist/assemble/evidenceReconciliationFromSources.js +30 -325
- package/dist/assemble/evidenceReconciliationFromSources.js.map +1 -1
- package/dist/assemble/renderInput.d.ts +7 -73
- package/dist/assemble/renderInput.d.ts.map +1 -1
- package/dist/assemble/renderInput.js +3 -45
- package/dist/assemble/renderInput.js.map +1 -1
- package/dist/census/evidenceObligations.d.ts +11 -46
- package/dist/census/evidenceObligations.d.ts.map +1 -1
- package/dist/census/evidenceObligations.js +19 -25
- package/dist/census/evidenceObligations.js.map +1 -1
- package/dist/domain/evidenceOrder.d.ts +3 -0
- package/dist/domain/evidenceOrder.d.ts.map +1 -0
- package/dist/domain/evidenceOrder.js +15 -0
- package/dist/domain/evidenceOrder.js.map +1 -0
- package/dist/domain/evidenceReconciliation.d.ts +21 -391
- package/dist/domain/evidenceReconciliation.d.ts.map +1 -1
- package/dist/domain/evidenceReconciliation.js +87 -382
- package/dist/domain/evidenceReconciliation.js.map +1 -1
- package/dist/domain/featureCode.d.ts +4 -0
- package/dist/domain/featureCode.d.ts.map +1 -0
- package/dist/domain/featureCode.js +12 -0
- package/dist/domain/featureCode.js.map +1 -0
- package/dist/domain/journal.d.ts +8 -393
- package/dist/domain/journal.d.ts.map +1 -1
- package/dist/domain/journal.js +6 -118
- package/dist/domain/journal.js.map +1 -1
- package/dist/domain/ledger.d.ts +8 -328
- package/dist/domain/ledger.d.ts.map +1 -1
- package/dist/domain/ledger.js +23 -326
- package/dist/domain/ledger.js.map +1 -1
- package/dist/domain/messages.d.ts +213 -0
- package/dist/domain/messages.d.ts.map +1 -0
- package/dist/domain/messages.js +313 -0
- package/dist/domain/messages.js.map +1 -0
- package/dist/domain/outcome.d.ts +3 -0
- package/dist/domain/outcome.d.ts.map +1 -0
- package/dist/domain/outcome.js +2 -0
- package/dist/domain/outcome.js.map +1 -0
- package/dist/domain/posting.d.ts +8 -105
- package/dist/domain/posting.d.ts.map +1 -1
- package/dist/domain/posting.js +4 -56
- package/dist/domain/posting.js.map +1 -1
- package/dist/domain/qualityCheckFault.d.ts +3 -43
- package/dist/domain/qualityCheckFault.d.ts.map +1 -1
- package/dist/domain/qualityCheckFault.js +0 -24
- package/dist/domain/qualityCheckFault.js.map +1 -1
- package/dist/domain/qualityCheckReconciliation.d.ts +7 -280
- package/dist/domain/qualityCheckReconciliation.d.ts.map +1 -1
- package/dist/domain/qualityCheckReconciliation.js +63 -463
- package/dist/domain/qualityCheckReconciliation.js.map +1 -1
- package/dist/domain/qualityCheckReconciliationFault.d.ts +0 -19
- package/dist/domain/qualityCheckReconciliationFault.d.ts.map +1 -1
- package/dist/domain/qualityCheckReconciliationFault.js +1 -24
- package/dist/domain/qualityCheckReconciliationFault.js.map +1 -1
- package/dist/domain/scenarioCodeError.d.ts +16 -0
- package/dist/domain/scenarioCodeError.d.ts.map +1 -0
- package/dist/domain/scenarioCodeError.js +4 -0
- package/dist/domain/scenarioCodeError.js.map +1 -0
- package/dist/domain/scenarioReconciliation.d.ts +2 -207
- package/dist/domain/scenarioReconciliation.d.ts.map +1 -1
- package/dist/domain/scenarioReconciliation.js +4 -101
- package/dist/domain/scenarioReconciliation.js.map +1 -1
- package/dist/domain/scnAllocation.d.ts +27 -0
- package/dist/domain/scnAllocation.d.ts.map +1 -0
- package/dist/domain/scnAllocation.js +33 -0
- package/dist/domain/scnAllocation.js.map +1 -0
- package/dist/domain/verdictCode.d.ts +10 -0
- package/dist/domain/verdictCode.d.ts.map +1 -0
- package/dist/domain/verdictCode.js +16 -0
- package/dist/domain/verdictCode.js.map +1 -0
- package/dist/index.d.ts +14 -40
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +8 -88
- package/dist/index.js.map +1 -1
- package/dist/internal.d.ts +3 -27
- package/dist/internal.d.ts.map +1 -1
- package/dist/internal.js +3 -94
- package/dist/internal.js.map +1 -1
- package/dist/lib/bareTerm.d.ts +0 -39
- package/dist/lib/bareTerm.d.ts.map +1 -1
- package/dist/lib/bareTerm.js +0 -39
- package/dist/lib/bareTerm.js.map +1 -1
- package/dist/lib/portablePath.d.ts.map +1 -1
- package/dist/lib/portablePath.js +2 -16
- package/dist/lib/portablePath.js.map +1 -1
- package/dist/lib/scnCitation.d.ts +0 -32
- package/dist/lib/scnCitation.d.ts.map +1 -1
- package/dist/lib/scnCitation.js +2 -42
- package/dist/lib/scnCitation.js.map +1 -1
- package/dist/model.d.ts +0 -23
- package/dist/model.d.ts.map +1 -1
- package/dist/model.js +0 -23
- package/dist/model.js.map +1 -1
- package/dist/parse/checkScriptsRunInCI.d.ts +5 -168
- package/dist/parse/checkScriptsRunInCI.d.ts.map +1 -1
- package/dist/parse/checkScriptsRunInCI.js +11 -171
- package/dist/parse/checkScriptsRunInCI.js.map +1 -1
- package/dist/parse/ciStepRecord.d.ts +4 -118
- package/dist/parse/ciStepRecord.d.ts.map +1 -1
- package/dist/parse/ciStepRecord.js +18 -225
- package/dist/parse/ciStepRecord.js.map +1 -1
- package/dist/parse/commandRuns.d.ts +0 -39
- package/dist/parse/commandRuns.d.ts.map +1 -1
- package/dist/parse/commandRuns.js +6 -67
- package/dist/parse/commandRuns.js.map +1 -1
- package/dist/parse/cucumber.d.ts +0 -53
- package/dist/parse/cucumber.d.ts.map +1 -1
- package/dist/parse/cucumber.js +42 -146
- package/dist/parse/cucumber.js.map +1 -1
- package/dist/parse/discoveryScope.d.ts +1 -46
- package/dist/parse/discoveryScope.d.ts.map +1 -1
- package/dist/parse/discoveryScope.js +2 -57
- package/dist/parse/discoveryScope.js.map +1 -1
- package/dist/parse/fitnessCitations.d.ts +1 -72
- package/dist/parse/fitnessCitations.d.ts.map +1 -1
- package/dist/parse/fitnessCitations.js +3 -55
- package/dist/parse/fitnessCitations.js.map +1 -1
- package/dist/parse/reconcilerSteps.d.ts +0 -46
- package/dist/parse/reconcilerSteps.d.ts.map +1 -1
- package/dist/parse/reconcilerSteps.js +2 -64
- package/dist/parse/reconcilerSteps.js.map +1 -1
- package/dist/parse/runningFitnessFunctions.d.ts +9 -0
- package/dist/parse/runningFitnessFunctions.d.ts.map +1 -0
- package/dist/parse/runningFitnessFunctions.js +57 -0
- package/dist/parse/runningFitnessFunctions.js.map +1 -0
- package/dist/parse/scenarioCodeErrors.d.ts +11 -0
- package/dist/parse/scenarioCodeErrors.d.ts.map +1 -0
- package/dist/parse/scenarioCodeErrors.js +78 -0
- package/dist/parse/scenarioCodeErrors.js.map +1 -0
- package/dist/parse/scenarios.d.ts +3 -228
- package/dist/parse/scenarios.d.ts.map +1 -1
- package/dist/parse/scenarios.js +20 -457
- package/dist/parse/scenarios.js.map +1 -1
- package/dist/parse/stepAccounting.d.ts +0 -46
- package/dist/parse/stepAccounting.d.ts.map +1 -1
- package/dist/parse/stepAccounting.js +1 -55
- package/dist/parse/stepAccounting.js.map +1 -1
- package/dist/parse/stepExclusions.d.ts +0 -47
- package/dist/parse/stepExclusions.d.ts.map +1 -1
- package/dist/parse/stepExclusions.js +2 -50
- package/dist/parse/stepExclusions.js.map +1 -1
- package/dist/parse/stepNames.d.ts +0 -27
- package/dist/parse/stepNames.d.ts.map +1 -1
- package/dist/parse/stepNames.js +0 -27
- package/dist/parse/stepNames.js.map +1 -1
- package/dist/parse/targetCorpus.d.ts +1 -78
- package/dist/parse/targetCorpus.d.ts.map +1 -1
- package/dist/parse/targetCorpus.js +4 -46
- package/dist/parse/targetCorpus.js.map +1 -1
- package/dist/parse/targetManifest.d.ts +8 -146
- package/dist/parse/targetManifest.d.ts.map +1 -1
- package/dist/parse/targetManifest.js +48 -198
- package/dist/parse/targetManifest.js.map +1 -1
- package/dist/parse/vitest.d.ts +0 -60
- package/dist/parse/vitest.d.ts.map +1 -1
- package/dist/parse/vitest.js +4 -83
- package/dist/parse/vitest.js.map +1 -1
- package/dist/provenance/provenance.d.ts +2 -110
- package/dist/provenance/provenance.d.ts.map +1 -1
- package/dist/provenance/provenance.js +2 -58
- package/dist/provenance/provenance.js.map +1 -1
- package/dist/render/behaviouralRunners.d.ts +0 -29
- package/dist/render/behaviouralRunners.d.ts.map +1 -1
- package/dist/render/behaviouralRunners.js +6 -69
- package/dist/render/behaviouralRunners.js.map +1 -1
- package/dist/render/configurationNotRead.d.ts +3 -0
- package/dist/render/configurationNotRead.d.ts.map +1 -0
- package/dist/render/configurationNotRead.js +17 -0
- package/dist/render/configurationNotRead.js.map +1 -0
- package/dist/render/discoveryScope.d.ts +0 -37
- package/dist/render/discoveryScope.d.ts.map +1 -1
- package/dist/render/discoveryScope.js +3 -39
- package/dist/render/discoveryScope.js.map +1 -1
- package/dist/render/evidenceGrid.d.ts +1 -35
- package/dist/render/evidenceGrid.d.ts.map +1 -1
- package/dist/render/evidenceGrid.js +21 -103
- package/dist/render/evidenceGrid.js.map +1 -1
- package/dist/render/excludedSteps.d.ts +0 -26
- package/dist/render/excludedSteps.d.ts.map +1 -1
- package/dist/render/excludedSteps.js +4 -32
- package/dist/render/excludedSteps.js.map +1 -1
- package/dist/render/fitnessFunctions.d.ts +3 -0
- package/dist/render/fitnessFunctions.d.ts.map +1 -0
- package/dist/render/fitnessFunctions.js +12 -0
- package/dist/render/fitnessFunctions.js.map +1 -0
- package/dist/render/json.d.ts +0 -11
- package/dist/render/json.d.ts.map +1 -1
- package/dist/render/json.js +0 -11
- package/dist/render/json.js.map +1 -1
- package/dist/render/markdown.d.ts +1 -55
- package/dist/render/markdown.d.ts.map +1 -1
- package/dist/render/markdown.js +128 -467
- package/dist/render/markdown.js.map +1 -1
- package/dist/render/provenanceSection.d.ts +0 -22
- package/dist/render/provenanceSection.d.ts.map +1 -1
- package/dist/render/provenanceSection.js +10 -53
- package/dist/render/provenanceSection.js.map +1 -1
- package/dist/render/reconcilerSteps.d.ts +0 -25
- package/dist/render/reconcilerSteps.d.ts.map +1 -1
- package/dist/render/reconcilerSteps.js +5 -30
- package/dist/render/reconcilerSteps.js.map +1 -1
- package/dist/render/runVerdict.d.ts +0 -38
- package/dist/render/runVerdict.d.ts.map +1 -1
- package/dist/render/runVerdict.js +62 -129
- package/dist/render/runVerdict.js.map +1 -1
- package/dist/render/scenarioCodeErrorsSection.d.ts +3 -0
- package/dist/render/scenarioCodeErrorsSection.d.ts.map +1 -0
- package/dist/render/scenarioCodeErrorsSection.js +45 -0
- package/dist/render/scenarioCodeErrorsSection.js.map +1 -0
- package/dist/render/stepAccounting.d.ts +0 -36
- package/dist/render/stepAccounting.d.ts.map +1 -1
- package/dist/render/stepAccounting.js +5 -49
- package/dist/render/stepAccounting.js.map +1 -1
- package/dist/render/testVolume.d.ts +0 -25
- package/dist/render/testVolume.d.ts.map +1 -1
- package/dist/render/testVolume.js +4 -35
- package/dist/render/testVolume.js.map +1 -1
- package/package.json +4 -1
- package/dist/domain/checkCharacteristics.d.ts +0 -88
- package/dist/domain/checkCharacteristics.d.ts.map +0 -1
- package/dist/domain/checkCharacteristics.js +0 -109
- package/dist/domain/checkCharacteristics.js.map +0 -1
- package/dist/domain/fitnessChecks.d.ts +0 -79
- package/dist/domain/fitnessChecks.d.ts.map +0 -1
- package/dist/domain/fitnessChecks.js +0 -81
- package/dist/domain/fitnessChecks.js.map +0 -1
- package/dist/domain/qualityCheckFaultMessages.d.ts +0 -43
- package/dist/domain/qualityCheckFaultMessages.d.ts.map +0 -1
- package/dist/domain/qualityCheckFaultMessages.js +0 -38
- package/dist/domain/qualityCheckFaultMessages.js.map +0 -1
- package/dist/lib/featureCode.d.ts +0 -21
- package/dist/lib/featureCode.d.ts.map +0 -1
- package/dist/lib/featureCode.js +0 -24
- package/dist/lib/featureCode.js.map +0 -1
- package/dist/parse/corpusCodeFaults.d.ts +0 -76
- package/dist/parse/corpusCodeFaults.d.ts.map +0 -1
- package/dist/parse/corpusCodeFaults.js +0 -121
- package/dist/parse/corpusCodeFaults.js.map +0 -1
- package/dist/parse/corpusFaults.d.ts +0 -124
- package/dist/parse/corpusFaults.d.ts.map +0 -1
- package/dist/parse/corpusFaults.js +0 -72
- package/dist/parse/corpusFaults.js.map +0 -1
- package/dist/parse/corpusGrammarFaults.d.ts +0 -71
- package/dist/parse/corpusGrammarFaults.d.ts.map +0 -1
- package/dist/parse/corpusGrammarFaults.js +0 -292
- package/dist/parse/corpusGrammarFaults.js.map +0 -1
- package/dist/parse/runningStaticChecks.d.ts +0 -125
- package/dist/parse/runningStaticChecks.d.ts.map +0 -1
- package/dist/parse/runningStaticChecks.js +0 -316
- package/dist/parse/runningStaticChecks.js.map +0 -1
- package/dist/render/staticChecks.d.ts +0 -23
- package/dist/render/staticChecks.d.ts.map +0 -1
- package/dist/render/staticChecks.js +0 -69
- package/dist/render/staticChecks.js.map +0 -1
|
@@ -1,123 +1,9 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
* axis, and the second of this axis's two readers (@SCN-LNT-021, @SCN-LNT-028).
|
|
4
|
-
*
|
|
5
|
-
* THE OTHER ONE READS A DIFFERENT DOCUMENT AND ANSWERS A DIFFERENT QUESTION. `runningStaticChecks`
|
|
6
|
-
* and `checkScriptsRunInCI` read the workflow FILE and answer "is this check wired into this
|
|
7
|
-
* pipeline, and which row does its step cite" — a fact about a repository, true between runs. This
|
|
8
|
-
* reads the RUN's record and answers "did it run this time, and what did it find" — a fact about
|
|
9
|
-
* one afternoon. Neither can be got from the other's document, which is why there are two.
|
|
10
|
-
*
|
|
11
|
-
* THE RECORD IS THE CONSUMER'S, WRITTEN BY NEITHER PARTY. It is what a job's own `toJSON(steps)`
|
|
12
|
-
* dumps: one entry per step that carried an `id:`, keyed by that id, each carrying the step's
|
|
13
|
-
* `outcome` and its `conclusion`. Nothing here executes a check, and nothing asks a consumer to
|
|
14
|
-
* move a command out of their pipeline — the check already ran, as their own CI step.
|
|
15
|
-
*
|
|
16
|
-
* THE KEY IS THE CITATION AND THE ROW SUPPLIES THE REST. A step's `id:` is a CODE and never a
|
|
17
|
-
* characteristic, so an entry naming a configured row is read for its verdict and the row it names
|
|
18
|
-
* is read for the characteristic that verdict answers — two terms from two places, the same
|
|
19
|
-
* arrangement the derivation side takes off a step's `id:`. An entry no configured row answers is
|
|
20
|
-
* not this reader's business: `checkout` and `setup-node` are not checks, and silence about them
|
|
21
|
-
* is the correct report rather than a gap in one.
|
|
22
|
-
*
|
|
23
|
-
* AND THE ROWS ARE READ TOO, NOT ONLY THE RECORD (@SCN-LNT-027). An entry is one half of the
|
|
24
|
-
* reading; the other is every configured row the record held no entry for, which is broken evidence
|
|
25
|
-
* naming that row. It is the one comparison on this axis that survives its own subject vanishing:
|
|
26
|
-
* the rows come from the target's manifest and the enumeration from the run's own record, so
|
|
27
|
-
* emptying either leaves the other standing. Every other reading here loses both sides at once when
|
|
28
|
-
* a check stops being wired, and a run over nothing balances.
|
|
29
|
-
*
|
|
30
|
-
* A RECORD NEVER HANDED OVER IS NOT A RECORD CARRYING NOTHING, AND THE OPTIONALITY REACHES THIS
|
|
31
|
-
* MODULE rather than being flattened at the call site. `undefined` is a consumer whose pipeline
|
|
32
|
-
* dumps no record, or a run nobody recorded: nothing is raised, the rows reconcile missing by
|
|
33
|
-
* absence and the run is out of balance, exactly as before. An EMPTY record is a run that happened
|
|
34
|
-
* and named not one of these steps, which is every configured check that did not run. Calling the
|
|
35
|
-
* first consumer's set-up broken over a file they have no reason to own is the fault the
|
|
36
|
-
* self-reconciliation gate already refuses one level up.
|
|
37
|
-
*
|
|
38
|
-
* PURE AND INJECTED, like every reader on this axis: the record arrives as data, parsed at the app
|
|
39
|
-
* edge from the target's own evidence, and the rows arrive from the target's own manifest.
|
|
40
|
-
*/
|
|
41
|
-
import type { FitnessCheckIndex } from "../domain/fitnessChecks.js";
|
|
42
|
-
import type { GuardEvidenceObservation } from "../model.js";
|
|
43
|
-
/**
|
|
44
|
-
* ONE STEP'S ENTRY in the record, as the dump wrote it.
|
|
45
|
-
*
|
|
46
|
-
* BOTH FIELDS ARE OPTIONAL BECAUSE THE DOCUMENT IS SOMEBODY ELSE'S. It is JSON a consumer's CI
|
|
47
|
-
* wrote and this reader was handed; a shape that declared either field present would be asserting
|
|
48
|
-
* something about a file nobody here validated, and the first record written by a provider that
|
|
49
|
-
* spells things differently would be a type error wearing a crash.
|
|
50
|
-
*/
|
|
51
|
-
export interface CiStepRecordEntry {
|
|
52
|
-
/**
|
|
53
|
-
* WHAT THE STEP ACTUALLY DID — pre-`continue-on-error`, and the field this axis reads.
|
|
54
|
-
*
|
|
55
|
-
* `success`, `failure`, `skipped` or `cancelled` on the provider this reader was built against.
|
|
56
|
-
* It is a string rather than a union for the reason the two fields are optional: the document is
|
|
57
|
-
* the consumer's, and a status nobody anticipated is a reading to fall through rather than a
|
|
58
|
-
* value the type system can forbid a foreign file from containing.
|
|
59
|
-
*/
|
|
1
|
+
import type { FitnessEvidenceObservation } from "../model.js";
|
|
2
|
+
interface CiStepRecordEntry {
|
|
60
3
|
readonly outcome?: string;
|
|
61
|
-
/**
|
|
62
|
-
* WHAT THE JOB WAS TOLD — post-`continue-on-error`, and the laundered value.
|
|
63
|
-
*
|
|
64
|
-
* Carried on the type because it is in the document, and read by nothing: a step marked
|
|
65
|
-
* `continue-on-error: true` that failed reports `success` here, so a reader taking this field is
|
|
66
|
-
* green over a masked failure. WHICH of the two fields a reader must take is its own claim with
|
|
67
|
-
* its own scenario (3F-3264); what this type does is stop the laundered one being reachable by
|
|
68
|
-
* accident under a name that reads like the real one.
|
|
69
|
-
*/
|
|
70
4
|
readonly conclusion?: string;
|
|
71
5
|
}
|
|
72
|
-
/**
|
|
73
|
-
* THE RECORD — every step that carried an `id:`, keyed by that id.
|
|
74
|
-
*
|
|
75
|
-
* A step with no `id:` is absent from it entirely, which is the provider's own arrangement and not
|
|
76
|
-
* a loss: a step nobody named cites nothing, and the record has no key to file it under.
|
|
77
|
-
*/
|
|
78
6
|
export type CiStepRecord = Readonly<Record<string, CiStepRecordEntry>>;
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
* WHAT ITS STEP DID: `satisfied` off a step that succeeded (@SCN-LNT-021) and `failing` off one
|
|
82
|
-
* that failed (@SCN-LNT-028). There is no third answer: a step the record says was skipped is
|
|
83
|
-
* broken evidence, whatever its row says (3F-3252).
|
|
84
|
-
*
|
|
85
|
-
* AND BROKEN EVIDENCE OFF EVERY OTHER READING (@SCN-LNT-026), which is why this is one per configured
|
|
86
|
-
* entry rather than one per entry that said something. The credit set is CLOSED to the three readings
|
|
87
|
-
* that say what the check did; a skip no row asked for, a `cancelled` step, a status nobody
|
|
88
|
-
* anticipated are each a step whose running this reader cannot vouch for, and the safe answer is the
|
|
89
|
-
* loud one — no Evidence Observation, the obligation reconciling missing by absence, and the run
|
|
90
|
-
* stamped unsound. Raising nothing at all would leave a check that stopped running indistinguishable
|
|
91
|
-
* from one nobody ever wrote, and send the reader to write it.
|
|
92
|
-
*
|
|
93
|
-
* THE CREDIT ARRIVES ALREADY CITING, WHICH IS THE SEAM THIS ROUTE RETIRES (@SCN-LNT-021). A
|
|
94
|
-
* DISCOVERED check is found as a runnable script handle, and a handle does not know what it is
|
|
95
|
-
* for — hence the (now-retired) registry, and hence the corpus lookup behind it. Here the
|
|
96
|
-
* entry's key IS the code of the row it answers and that row carries the characteristic: two
|
|
97
|
-
* terms from two places, neither resolved onto the other and no registry consulted at all.
|
|
98
|
-
*
|
|
99
|
-
* `failing`, AND THE THREE NEIGHBOURS IT IS NOT. `broken` is the never-ran case: it carries no
|
|
100
|
-
* Evidence Observation and stamps the run unsound, so reading a failed step as broken would throw
|
|
101
|
-
* away the one thing the check actually said. `missing` says no evidence, and there is evidence.
|
|
102
|
-
* A credit that said only "it ran" leaves the row balanced over a check that found violations,
|
|
103
|
-
* which is this axis's own headline fault arriving by the front door. What is left is the word
|
|
104
|
-
* every other axis already uses for present-and-failing.
|
|
105
|
-
*
|
|
106
|
-
* THE VERDICT TRAVELS ON THE OBSERVATION BECAUSE NOTHING ELSE CARRIES IT ANY MORE. While a runner
|
|
107
|
-
* ran the checks, a check that found violations reddened the run through the runner's exit code
|
|
108
|
-
* and the credit only had to say the check ran. A CI step's exit code reaches this ledger nowhere.
|
|
109
|
-
*
|
|
110
|
-
* BOTH `exists` AND `enforcedOverRealSource` ARE OBSERVED HERE, NOT INFERRED, which is why they
|
|
111
|
-
* are asserted at all. The step RAN — that is what the record says — and it ran in the target's
|
|
112
|
-
* own checkout, over the target's own tree. Neither is the manifest-mentions-a-name reading the
|
|
113
|
-
* discovered route takes.
|
|
114
|
-
*
|
|
115
|
-
* AN ENTRY NO CONFIGURED ROW ANSWERS IS NOT THIS READER'S BUSINESS. `checkout`, `setup-node` and
|
|
116
|
-
* the dump step itself are steps and not checks, and silence about them is the correct report.
|
|
117
|
-
*
|
|
118
|
-
* AND A CONFIGURED ROW NO ENTRY ANSWERS RAISES A BROKEN CREDIT (@SCN-LNT-027), which is why this
|
|
119
|
-
* walks the ROWS as well as the record. The rows are the denominator, and a check quietly lifted
|
|
120
|
-
* out of a pipeline goes dark on the side the pipeline cannot reach.
|
|
121
|
-
*/
|
|
122
|
-
export declare function ciStepRecordCredits(record: CiStepRecord | undefined, fitnessChecks: FitnessCheckIndex): GuardEvidenceObservation[];
|
|
7
|
+
export declare function ciStepRecordCredits(record: CiStepRecord | undefined): FitnessEvidenceObservation[];
|
|
8
|
+
export {};
|
|
123
9
|
//# sourceMappingURL=ciStepRecord.d.ts.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"ciStepRecord.d.ts","sourceRoot":"","sources":["../../src/parse/ciStepRecord.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"ciStepRecord.d.ts","sourceRoot":"","sources":["../../src/parse/ciStepRecord.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,EAAE,0BAA0B,EAAE,MAAM,aAAa,CAAC;AAE9D,UAAU,iBAAiB;IACzB,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;CAC9B;AAED,MAAM,MAAM,YAAY,GAAG,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,iBAAiB,CAAC,CAAC,CAAC;AAsDvE,wBAAgB,mBAAmB,CAAC,MAAM,EAAE,YAAY,GAAG,SAAS,GAAG,0BAA0B,EAAE,CAQlG"}
|
|
@@ -1,85 +1,8 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
* axis, and the second of this axis's two readers (@SCN-LNT-021, @SCN-LNT-028).
|
|
4
|
-
*
|
|
5
|
-
* THE OTHER ONE READS A DIFFERENT DOCUMENT AND ANSWERS A DIFFERENT QUESTION. `runningStaticChecks`
|
|
6
|
-
* and `checkScriptsRunInCI` read the workflow FILE and answer "is this check wired into this
|
|
7
|
-
* pipeline, and which row does its step cite" — a fact about a repository, true between runs. This
|
|
8
|
-
* reads the RUN's record and answers "did it run this time, and what did it find" — a fact about
|
|
9
|
-
* one afternoon. Neither can be got from the other's document, which is why there are two.
|
|
10
|
-
*
|
|
11
|
-
* THE RECORD IS THE CONSUMER'S, WRITTEN BY NEITHER PARTY. It is what a job's own `toJSON(steps)`
|
|
12
|
-
* dumps: one entry per step that carried an `id:`, keyed by that id, each carrying the step's
|
|
13
|
-
* `outcome` and its `conclusion`. Nothing here executes a check, and nothing asks a consumer to
|
|
14
|
-
* move a command out of their pipeline — the check already ran, as their own CI step.
|
|
15
|
-
*
|
|
16
|
-
* THE KEY IS THE CITATION AND THE ROW SUPPLIES THE REST. A step's `id:` is a CODE and never a
|
|
17
|
-
* characteristic, so an entry naming a configured row is read for its verdict and the row it names
|
|
18
|
-
* is read for the characteristic that verdict answers — two terms from two places, the same
|
|
19
|
-
* arrangement the derivation side takes off a step's `id:`. An entry no configured row answers is
|
|
20
|
-
* not this reader's business: `checkout` and `setup-node` are not checks, and silence about them
|
|
21
|
-
* is the correct report rather than a gap in one.
|
|
22
|
-
*
|
|
23
|
-
* AND THE ROWS ARE READ TOO, NOT ONLY THE RECORD (@SCN-LNT-027). An entry is one half of the
|
|
24
|
-
* reading; the other is every configured row the record held no entry for, which is broken evidence
|
|
25
|
-
* naming that row. It is the one comparison on this axis that survives its own subject vanishing:
|
|
26
|
-
* the rows come from the target's manifest and the enumeration from the run's own record, so
|
|
27
|
-
* emptying either leaves the other standing. Every other reading here loses both sides at once when
|
|
28
|
-
* a check stops being wired, and a run over nothing balances.
|
|
29
|
-
*
|
|
30
|
-
* A RECORD NEVER HANDED OVER IS NOT A RECORD CARRYING NOTHING, AND THE OPTIONALITY REACHES THIS
|
|
31
|
-
* MODULE rather than being flattened at the call site. `undefined` is a consumer whose pipeline
|
|
32
|
-
* dumps no record, or a run nobody recorded: nothing is raised, the rows reconcile missing by
|
|
33
|
-
* absence and the run is out of balance, exactly as before. An EMPTY record is a run that happened
|
|
34
|
-
* and named not one of these steps, which is every configured check that did not run. Calling the
|
|
35
|
-
* first consumer's set-up broken over a file they have no reason to own is the fault the
|
|
36
|
-
* self-reconciliation gate already refuses one level up.
|
|
37
|
-
*
|
|
38
|
-
* PURE AND INJECTED, like every reader on this axis: the record arrives as data, parsed at the app
|
|
39
|
-
* edge from the target's own evidence, and the rows arrive from the target's own manifest.
|
|
40
|
-
*/
|
|
41
|
-
/** The provider's own two words for a step that RAN, spelled once each. */
|
|
1
|
+
import { SCN_CODE } from "./scenarios.js";
|
|
2
|
+
import { CORE_MESSAGES, CoreMessage } from "../domain/messages.js";
|
|
42
3
|
const SUCCESS = "success";
|
|
43
4
|
const FAILURE = "failure";
|
|
44
|
-
/** And its word for a step that did not — the one reading a ROW can ask to be credited for. */
|
|
45
5
|
const SKIPPED = "skipped";
|
|
46
|
-
/**
|
|
47
|
-
* WHAT THE CHECK ITSELF SAID, read off the step's own result — or `null` where this reader has no
|
|
48
|
-
* reading for what the record says (@SCN-LNT-021, @SCN-LNT-028).
|
|
49
|
-
*
|
|
50
|
-
* TWO READINGS SAY WHAT THE CHECK DID AND EVERYTHING ELSE FALLS THROUGH, which is the fail-safe
|
|
51
|
-
* direction written as a shape rather than as a warning. A step that succeeded ran and found
|
|
52
|
-
* nothing; a step that failed ran and found something; and both of those are facts about a check,
|
|
53
|
-
* which is why both raise a credit and the credit carries WHICH. Every other reading — any skip
|
|
54
|
-
* whatever its cause, `cancelled`, a status nobody anticipated, or no entry for the row at all —
|
|
55
|
-
* is a step this reader cannot vouch for having run, and what such a step earns is BROKEN evidence
|
|
56
|
-
* rather than the credit (@SCN-LNT-026): the `null` is a fall-through to the other shape, never a
|
|
57
|
-
* silence.
|
|
58
|
-
*
|
|
59
|
-
* THERE IS NO THIRD READING FOR "THE COMMAND EXAMINED NOTHING", AND THE REASON IS THAT A SKIP
|
|
60
|
-
* CANNOT MEAN IT (3F-3252). A row used to declare the ending its command says so with, and the
|
|
61
|
-
* retired fitness pass SPAWNED that command and compared the number. Here nothing of ours spawns
|
|
62
|
-
* anything: the consumer's CI runs it, and a command that examines nothing still RUNS — it exits,
|
|
63
|
-
* so its step reads success or failure. It is never `skipped`. A step is skipped when a condition
|
|
64
|
-
* went false, when the job was cancelled, or when somebody moved it — and none of those is the
|
|
65
|
-
* check examining nothing.
|
|
66
|
-
*
|
|
67
|
-
* SO A READING THAT FORGAVE A SKIP ON THE STRENGTH OF A DECLARED ENDING WOULD BE A HATCH. The
|
|
68
|
-
* declaration could only be read for WHETHER it was named — no code crosses a step record to check
|
|
69
|
-
* it against — so `if: false` beside a declared ending would read SATISFIED for ever: a check
|
|
70
|
-
* switched off, green in the ledger, through the product's own configuration, and single-entry in
|
|
71
|
-
* the double-entry product. The field is gone rather than guarded.
|
|
72
|
-
*
|
|
73
|
-
* A CONSUMER WHOSE COMMAND GENUINELY EXAMINES NOTHING SAYS SO IN THEIR OWN `run:` LINE —
|
|
74
|
-
* `eslint || [ $? -eq 3 ]` — where it becomes an honest success their CI records. That is their
|
|
75
|
-
* business, on their side of the boundary, and it needs nothing from our row.
|
|
76
|
-
*
|
|
77
|
-
* THE VERDICT IS CARRIED RATHER THAN COLLAPSED, and that is what this route does not share with
|
|
78
|
-
* the retired fitness pass's reader. While a runner ran the checks, a check that found violations
|
|
79
|
-
* reddened the run through the runner's exit code and its credit only had to say the check ran — so passed
|
|
80
|
-
* and failed were honestly one answer there. A CI step's exit code reaches this ledger nowhere: if
|
|
81
|
-
* the credit does not carry the verdict, nothing does.
|
|
82
|
-
*/
|
|
83
6
|
function readingOf(outcome) {
|
|
84
7
|
if (outcome === SUCCESS)
|
|
85
8
|
return { status: "passed" };
|
|
@@ -87,178 +10,48 @@ function readingOf(outcome) {
|
|
|
87
10
|
return { status: "failed" };
|
|
88
11
|
return null;
|
|
89
12
|
}
|
|
90
|
-
/**
|
|
91
|
-
* WHAT THE RECORD SAID AND WHY THAT IS NOT A CREDIT — the whole of the record's answer about this
|
|
92
|
-
* check, so it is written as one sentence (@SCN-LNT-026).
|
|
93
|
-
*
|
|
94
|
-
* IT IS ALL A READER GETS, which is why it says three things and no more. A broken item carries no
|
|
95
|
-
* Evidence Observation, so this sentence names the subject, states the diagnosis, and prescribes NO
|
|
96
|
-
* cure — which of a condition that went false, a cancelled job, a step somebody moved or a provider
|
|
97
|
-
* that spells things differently produced the reading is not this reader's to say, and naming one
|
|
98
|
-
* would send the reader to the wrong file.
|
|
99
|
-
*
|
|
100
|
-
* THE SKIP ARM NAMES THE THREE THINGS THAT CAUSE A SKIP, because a reader meeting this line will
|
|
101
|
-
* otherwise go hunting for a broken command that is working perfectly. No row can excuse a skip:
|
|
102
|
-
* a command that examines nothing still runs and still ends, so a skip is never that (3F-3252).
|
|
103
|
-
*/
|
|
104
13
|
function checkDidNotRunMessage(scnId, outcome) {
|
|
105
|
-
if (outcome === undefined)
|
|
106
|
-
return
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
}
|
|
111
|
-
return `${scnId}: the CI run's record says this check's step ended \`${outcome}\` — so the check did not run.`;
|
|
14
|
+
if (outcome === undefined)
|
|
15
|
+
return CORE_MESSAGES[CoreMessage.CheckStepNoOutcome](scnId);
|
|
16
|
+
if (outcome === SKIPPED)
|
|
17
|
+
return CORE_MESSAGES[CoreMessage.CheckStepSkipped](scnId);
|
|
18
|
+
return CORE_MESSAGES[CoreMessage.CheckStepEnded](scnId, outcome);
|
|
112
19
|
}
|
|
113
|
-
|
|
114
|
-
* ONE ENTRY'S CREDIT — the ordinary one where the record says what the check did, and BROKEN
|
|
115
|
-
* evidence where it does not (@SCN-LNT-026).
|
|
116
|
-
*
|
|
117
|
-
* ONE FUNCTION FOR BOTH BECAUSE IT IS ONE DECISION. The two observations differ in what they say
|
|
118
|
-
* about the same check, so writing them apart would put the question in one place and its two
|
|
119
|
-
* answers in two — and the day a field is added to one of them is the day they stop agreeing about
|
|
120
|
-
* anything but the fields somebody remembered.
|
|
121
|
-
*
|
|
122
|
-
* THE BROKEN ONE CARRIES BOTH FACTS AS `false` RATHER THAN OMITTING THEM. `exists` and
|
|
123
|
-
* `enforcedOverRealSource` are OBSERVATIONS on this route — the record saying a step ran is what
|
|
124
|
-
* says the check exists and ran over the consumer's own checkout — and neither was observed here,
|
|
125
|
-
* so the honest values are the ones that assert nothing. It is also what keeps the roll-up right: a
|
|
126
|
-
* check that did not run is not a running static check.
|
|
127
|
-
*
|
|
128
|
-
* AND IT CARRIES ITS `@SCN` AND ITS CHARACTERISTIC, which are known and true. What stops those
|
|
129
|
-
* being read as a citation is the reconciler's two fail-safes — `postingOf` takes `broken` before
|
|
130
|
-
* `scnId`, and the obligation match excludes it — never their absence.
|
|
131
|
-
*/
|
|
132
|
-
function namedOf(citedScn, row) {
|
|
20
|
+
function namedOf(citedScn) {
|
|
133
21
|
return {
|
|
134
|
-
qualityCheck: "
|
|
135
|
-
|
|
136
|
-
// in either: the record knows a step id, and an id is a code and never a characteristic.
|
|
137
|
-
// `staticCheck` is where-to-fix and `checkTag` is what the reconciler matches on, and for this
|
|
138
|
-
// route the row's one word is the whole of what there is to name.
|
|
139
|
-
staticCheck: row.characteristic,
|
|
22
|
+
qualityCheck: "fitness",
|
|
23
|
+
fitnessFunction: citedScn,
|
|
140
24
|
scnId: citedScn,
|
|
141
|
-
checkTag: row.characteristic,
|
|
142
25
|
};
|
|
143
26
|
}
|
|
144
|
-
|
|
145
|
-
* The BROKEN shape, spelled once for both the readings that reach it — an entry whose outcome this
|
|
146
|
-
* reader cannot vouch for (@SCN-LNT-026), and a configured row the record held no entry for at all
|
|
147
|
-
* (@SCN-LNT-027).
|
|
148
|
-
*
|
|
149
|
-
* ONE SPELLING BECAUSE IT IS ONE OUTCOME. The two readings differ in what they say about the check
|
|
150
|
-
* and in nothing else, so a second construction here would be free to omit a field the first
|
|
151
|
-
* carries — and the day one of them stopped carrying `exists: false` is the day a check that did
|
|
152
|
-
* not run started counting as a running one on exactly half the routes.
|
|
153
|
-
*/
|
|
154
|
-
function brokenCreditOf(citedScn, row, message) {
|
|
27
|
+
function brokenCreditOf(citedScn, message) {
|
|
155
28
|
return {
|
|
156
|
-
...namedOf(citedScn
|
|
29
|
+
...namedOf(citedScn),
|
|
157
30
|
exists: false,
|
|
158
31
|
enforcedOverRealSource: false,
|
|
159
32
|
broken: true,
|
|
160
33
|
message,
|
|
161
34
|
};
|
|
162
35
|
}
|
|
163
|
-
function creditOf(citedScn,
|
|
36
|
+
function creditOf(citedScn, reading, outcome) {
|
|
164
37
|
if (reading === null) {
|
|
165
|
-
return brokenCreditOf(citedScn,
|
|
38
|
+
return brokenCreditOf(citedScn, checkDidNotRunMessage(citedScn, outcome));
|
|
166
39
|
}
|
|
167
40
|
return {
|
|
168
|
-
...namedOf(citedScn
|
|
169
|
-
// OBSERVED, NOT INFERRED, which is why both are asserted at all. The step RAN — that is what
|
|
170
|
-
// the record says — and it ran in the target's own checkout, over the target's own tree.
|
|
171
|
-
// Neither is the manifest-mentions-a-name reading the discovered route takes.
|
|
41
|
+
...namedOf(citedScn),
|
|
172
42
|
exists: true,
|
|
173
43
|
enforcedOverRealSource: true,
|
|
174
|
-
// THE VERDICT THE STEP REACHED, AND EVERY CREDIT CARRIES ONE. A step that ran reached either
|
|
175
|
-
// `passed` or `failed`; a step that did not is not a credit at all but broken evidence, so
|
|
176
|
-
// there is no third shape here (3F-3252).
|
|
177
44
|
...reading,
|
|
178
45
|
};
|
|
179
46
|
}
|
|
180
|
-
|
|
181
|
-
* WHAT the record said about a configured row it held no entry for, which is nothing at all — the
|
|
182
|
-
* message a row's own absence from the record earns (@SCN-LNT-027).
|
|
183
|
-
*
|
|
184
|
-
* IT NAMES THE MANIFEST RATHER THAN THE PIPELINE, because the manifest is the document this reader
|
|
185
|
-
* actually held. Which step should have carried the row's code is a real question and not one the
|
|
186
|
-
* record can answer: the entry it would live in is precisely what the record did not carry. Naming
|
|
187
|
-
* a workflow file this reader never read would be the prescribed cure a broken item refuses.
|
|
188
|
-
*
|
|
189
|
-
* IT IS NOT THE SENTENCE AN ENTRY WITH NO OUTCOME EARNS, and the two are kept apart because they
|
|
190
|
-
* send a reader to different places. That one is a step this run recorded and said nothing about;
|
|
191
|
-
* this one is a step the run did not record at all.
|
|
192
|
-
*/
|
|
193
|
-
function rowHasNoEntryMessage(scnId) {
|
|
194
|
-
return (`${scnId}: the CI run's record carries no step for this row of ` +
|
|
195
|
-
"`specController.fitnessChecks` — so the check did not run.");
|
|
196
|
-
}
|
|
197
|
-
/**
|
|
198
|
-
* The credits a CI RUN'S OWN RECORD raises — one per entry naming a configured row, carrying
|
|
199
|
-
* WHAT ITS STEP DID: `satisfied` off a step that succeeded (@SCN-LNT-021) and `failing` off one
|
|
200
|
-
* that failed (@SCN-LNT-028). There is no third answer: a step the record says was skipped is
|
|
201
|
-
* broken evidence, whatever its row says (3F-3252).
|
|
202
|
-
*
|
|
203
|
-
* AND BROKEN EVIDENCE OFF EVERY OTHER READING (@SCN-LNT-026), which is why this is one per configured
|
|
204
|
-
* entry rather than one per entry that said something. The credit set is CLOSED to the three readings
|
|
205
|
-
* that say what the check did; a skip no row asked for, a `cancelled` step, a status nobody
|
|
206
|
-
* anticipated are each a step whose running this reader cannot vouch for, and the safe answer is the
|
|
207
|
-
* loud one — no Evidence Observation, the obligation reconciling missing by absence, and the run
|
|
208
|
-
* stamped unsound. Raising nothing at all would leave a check that stopped running indistinguishable
|
|
209
|
-
* from one nobody ever wrote, and send the reader to write it.
|
|
210
|
-
*
|
|
211
|
-
* THE CREDIT ARRIVES ALREADY CITING, WHICH IS THE SEAM THIS ROUTE RETIRES (@SCN-LNT-021). A
|
|
212
|
-
* DISCOVERED check is found as a runnable script handle, and a handle does not know what it is
|
|
213
|
-
* for — hence the (now-retired) registry, and hence the corpus lookup behind it. Here the
|
|
214
|
-
* entry's key IS the code of the row it answers and that row carries the characteristic: two
|
|
215
|
-
* terms from two places, neither resolved onto the other and no registry consulted at all.
|
|
216
|
-
*
|
|
217
|
-
* `failing`, AND THE THREE NEIGHBOURS IT IS NOT. `broken` is the never-ran case: it carries no
|
|
218
|
-
* Evidence Observation and stamps the run unsound, so reading a failed step as broken would throw
|
|
219
|
-
* away the one thing the check actually said. `missing` says no evidence, and there is evidence.
|
|
220
|
-
* A credit that said only "it ran" leaves the row balanced over a check that found violations,
|
|
221
|
-
* which is this axis's own headline fault arriving by the front door. What is left is the word
|
|
222
|
-
* every other axis already uses for present-and-failing.
|
|
223
|
-
*
|
|
224
|
-
* THE VERDICT TRAVELS ON THE OBSERVATION BECAUSE NOTHING ELSE CARRIES IT ANY MORE. While a runner
|
|
225
|
-
* ran the checks, a check that found violations reddened the run through the runner's exit code
|
|
226
|
-
* and the credit only had to say the check ran. A CI step's exit code reaches this ledger nowhere.
|
|
227
|
-
*
|
|
228
|
-
* BOTH `exists` AND `enforcedOverRealSource` ARE OBSERVED HERE, NOT INFERRED, which is why they
|
|
229
|
-
* are asserted at all. The step RAN — that is what the record says — and it ran in the target's
|
|
230
|
-
* own checkout, over the target's own tree. Neither is the manifest-mentions-a-name reading the
|
|
231
|
-
* discovered route takes.
|
|
232
|
-
*
|
|
233
|
-
* AN ENTRY NO CONFIGURED ROW ANSWERS IS NOT THIS READER'S BUSINESS. `checkout`, `setup-node` and
|
|
234
|
-
* the dump step itself are steps and not checks, and silence about them is the correct report.
|
|
235
|
-
*
|
|
236
|
-
* AND A CONFIGURED ROW NO ENTRY ANSWERS RAISES A BROKEN CREDIT (@SCN-LNT-027), which is why this
|
|
237
|
-
* walks the ROWS as well as the record. The rows are the denominator, and a check quietly lifted
|
|
238
|
-
* out of a pipeline goes dark on the side the pipeline cannot reach.
|
|
239
|
-
*/
|
|
240
|
-
export function ciStepRecordCredits(record, fitnessChecks) {
|
|
47
|
+
export function ciStepRecordCredits(record) {
|
|
241
48
|
if (record === undefined)
|
|
242
49
|
return [];
|
|
243
50
|
const credits = [];
|
|
244
|
-
const recorded = new Set();
|
|
245
51
|
for (const [citedScn, step] of Object.entries(record)) {
|
|
246
|
-
|
|
247
|
-
if (row === undefined)
|
|
248
|
-
continue;
|
|
249
|
-
recorded.add(citedScn);
|
|
250
|
-
// NO `continue` ON A READING THIS READER HAS NONE FOR (@SCN-LNT-026). Every configured row the
|
|
251
|
-
// record holds an entry for raises something; which of the two shapes it raises is the
|
|
252
|
-
// credit builder's answer, and the fall-through reaches the loud one rather than the exit.
|
|
253
|
-
credits.push(creditOf(citedScn, row, readingOf(step.outcome), step.outcome));
|
|
254
|
-
}
|
|
255
|
-
// AND THE ROWS ARE WALKED TOO, NOT ONLY THE RECORD (@SCN-LNT-027). The rows come from the
|
|
256
|
-
// target's manifest and the enumeration from the run's own record, so a row the record held no
|
|
257
|
-
// entry for is a check that did not run — broken evidence naming that row.
|
|
258
|
-
for (const [scnId, row] of fitnessChecks) {
|
|
259
|
-
if (recorded.has(scnId))
|
|
52
|
+
if (!SCN_CODE.test(citedScn))
|
|
260
53
|
continue;
|
|
261
|
-
credits.push(
|
|
54
|
+
credits.push(creditOf(citedScn, readingOf(step.outcome), step.outcome));
|
|
262
55
|
}
|
|
263
56
|
return credits;
|
|
264
57
|
}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"ciStepRecord.js","sourceRoot":"","sources":["../../src/parse/ciStepRecord.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"ciStepRecord.js","sourceRoot":"","sources":["../../src/parse/ciStepRecord.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,gBAAgB,CAAC;AAE1C,OAAO,EAAE,aAAa,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAUnE,MAAM,OAAO,GAAG,SAAS,CAAC;AAC1B,MAAM,OAAO,GAAG,SAAS,CAAC;AAC1B,MAAM,OAAO,GAAG,SAAS,CAAC;AAI1B,SAAS,SAAS,CAAC,OAA2B;IAC5C,IAAI,OAAO,KAAK,OAAO;QAAE,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,CAAC;IACrD,IAAI,OAAO,KAAK,OAAO;QAAE,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,CAAC;IACrD,OAAO,IAAI,CAAC;AACd,CAAC;AAED,SAAS,qBAAqB,CAAC,KAAa,EAAE,OAA2B;IACvE,IAAI,OAAO,KAAK,SAAS;QAAE,OAAO,aAAa,CAAC,WAAW,CAAC,kBAAkB,CAAC,CAAC,KAAK,CAAC,CAAC;IACvF,IAAI,OAAO,KAAK,OAAO;QAAE,OAAO,aAAa,CAAC,WAAW,CAAC,gBAAgB,CAAC,CAAC,KAAK,CAAC,CAAC;IACnF,OAAO,aAAa,CAAC,WAAW,CAAC,cAAc,CAAC,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC;AACnE,CAAC;AAED,SAAS,OAAO,CAAC,QAAgB;IAC/B,OAAO;QACL,YAAY,EAAE,SAAS;QACvB,eAAe,EAAE,QAAQ;QACzB,KAAK,EAAE,QAAQ;KACP,CAAC;AACb,CAAC;AAED,SAAS,cAAc,CAAC,QAAgB,EAAE,OAAe;IACvD,OAAO;QACL,GAAG,OAAO,CAAC,QAAQ,CAAC;QACpB,MAAM,EAAE,KAAK;QACb,sBAAsB,EAAE,KAAK;QAC7B,MAAM,EAAE,IAAI;QACZ,OAAO;KACR,CAAC;AACJ,CAAC;AAED,SAAS,QAAQ,CACf,QAAgB,EAChB,OAAoB,EACpB,OAA2B;IAE3B,IAAI,OAAO,KAAK,IAAI,EAAE,CAAC;QACrB,OAAO,cAAc,CAAC,QAAQ,EAAE,qBAAqB,CAAC,QAAQ,EAAE,OAAO,CAAC,CAAC,CAAC;IAC5E,CAAC;IACD,OAAO;QACL,GAAG,OAAO,CAAC,QAAQ,CAAC;QACpB,MAAM,EAAE,IAAI;QACZ,sBAAsB,EAAE,IAAI;QAC5B,GAAG,OAAO;KACX,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB,CAAC,MAAgC;IAClE,IAAI,MAAM,KAAK,SAAS;QAAE,OAAO,EAAE,CAAC;IACpC,MAAM,OAAO,GAAiC,EAAE,CAAC;IACjD,KAAK,MAAM,CAAC,QAAQ,EAAE,IAAI,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,CAAC,EAAE,CAAC;QACtD,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,QAAQ,CAAC;YAAE,SAAS;QACvC,OAAO,CAAC,IAAI,CAAC,QAAQ,CAAC,QAAQ,EAAE,SAAS,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,IAAI,CAAC,OAAO,CAAC,CAAC,CAAC;IAC1E,CAAC;IACD,OAAO,OAAO,CAAC;AACjB,CAAC"}
|
|
@@ -1,41 +1,2 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* DOES THIS COMMAND RUN THAT — the one comparison every recognition rule on this axis makes, and
|
|
3
|
-
* it is made in one place because two of them now make it.
|
|
4
|
-
*
|
|
5
|
-
* WHOLE TOKENS, NEVER A SUBSTRING, and that is the whole of what keeps a recognition rule safe.
|
|
6
|
-
* Measured over 113 `run:` steps in five real pipelines (3F-3343) the substring form recognises 2
|
|
7
|
-
* and BOTH are false: one of them is the reconciler's own `balance` step, matched on the filename
|
|
8
|
-
* `vitest.json` inside its `--vitest` argument. Excluding a fitness check as something else is the
|
|
9
|
-
* one direction this axis cannot tolerate, because it is silent.
|
|
10
|
-
*
|
|
11
|
-
* THE SCRIPT HOP IS THE RULE, NOT A REFINEMENT OF IT. Over those same 113 steps the first clause
|
|
12
|
-
* ALONE recognises zero: every pipeline in the portfolio invokes its runner through a
|
|
13
|
-
* `package.json` script alias, and the binary's name is in the workflow only inside a path. A rule
|
|
14
|
-
* that resolved a step's command to the executable it runs could not be built from the workflow,
|
|
15
|
-
* because the executable is not there.
|
|
16
|
-
*
|
|
17
|
-
* WHICH SCRIPT A COMMAND INVOKES IS THE PRODUCT'S OWN QUESTION, already answered —
|
|
18
|
-
* `commandInvokesScript`, the exact package-manager invocation a static check's enforcement is
|
|
19
|
-
* read through. Asking it a second way here would let two readers disagree about what `pnpm test`
|
|
20
|
-
* invokes.
|
|
21
|
-
*
|
|
22
|
-
* AN INVOCATION OF MORE THAN ONE TOKEN IS MATCHED ADJACENT AND IN ORDER, which is what lets a
|
|
23
|
-
* caller name a tool AND the command it is being run for. `spec-controller balance` is the
|
|
24
|
-
* reconciler; `spec-controller tags` is the same binary doing something else, and this repository's
|
|
25
|
-
* own pipeline runs both — so a rule comparing the binary alone would take an ordinary step of the
|
|
26
|
-
* pipeline off the books. Per LINE, because two commands on two lines are two commands.
|
|
27
|
-
*
|
|
28
|
-
* Its own module rather than a private helper of the runner rule: the reconciler asks the same
|
|
29
|
-
* question (`parse/reconcilerSteps`), and a second implementation of "does this command run that"
|
|
30
|
-
* is a second chance for the two to answer differently about one step.
|
|
31
|
-
*/
|
|
32
|
-
/**
|
|
33
|
-
* Does this command run the named invocation — itself, or through the manifest scripts it invokes?
|
|
34
|
-
*
|
|
35
|
-
* AN INVOCATION OF NO TOKENS RUNS NOWHERE, which is the guard rather than a formality: an empty
|
|
36
|
-
* token list occurs at every position of every command, so a reader taking it as a match would
|
|
37
|
-
* recognise every step of every pipeline it was handed. A caller that has been told no invocation
|
|
38
|
-
* has been told nothing, and nothing is what it gets back.
|
|
39
|
-
*/
|
|
40
1
|
export declare function commandRuns(command: string, invocation: string, scripts: Readonly<Record<string, string>>): boolean;
|
|
41
2
|
//# sourceMappingURL=commandRuns.d.ts.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"commandRuns.d.ts","sourceRoot":"","sources":["../../src/parse/commandRuns.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"commandRuns.d.ts","sourceRoot":"","sources":["../../src/parse/commandRuns.ts"],"names":[],"mappings":"AA2BA,wBAAgB,WAAW,CACzB,OAAO,EAAE,MAAM,EACf,UAAU,EAAE,MAAM,EAClB,OAAO,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,GACxC,OAAO,CAGT"}
|
|
@@ -1,82 +1,21 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* DOES THIS COMMAND RUN THAT — the one comparison every recognition rule on this axis makes, and
|
|
3
|
-
* it is made in one place because two of them now make it.
|
|
4
|
-
*
|
|
5
|
-
* WHOLE TOKENS, NEVER A SUBSTRING, and that is the whole of what keeps a recognition rule safe.
|
|
6
|
-
* Measured over 113 `run:` steps in five real pipelines (3F-3343) the substring form recognises 2
|
|
7
|
-
* and BOTH are false: one of them is the reconciler's own `balance` step, matched on the filename
|
|
8
|
-
* `vitest.json` inside its `--vitest` argument. Excluding a fitness check as something else is the
|
|
9
|
-
* one direction this axis cannot tolerate, because it is silent.
|
|
10
|
-
*
|
|
11
|
-
* THE SCRIPT HOP IS THE RULE, NOT A REFINEMENT OF IT. Over those same 113 steps the first clause
|
|
12
|
-
* ALONE recognises zero: every pipeline in the portfolio invokes its runner through a
|
|
13
|
-
* `package.json` script alias, and the binary's name is in the workflow only inside a path. A rule
|
|
14
|
-
* that resolved a step's command to the executable it runs could not be built from the workflow,
|
|
15
|
-
* because the executable is not there.
|
|
16
|
-
*
|
|
17
|
-
* WHICH SCRIPT A COMMAND INVOKES IS THE PRODUCT'S OWN QUESTION, already answered —
|
|
18
|
-
* `commandInvokesScript`, the exact package-manager invocation a static check's enforcement is
|
|
19
|
-
* read through. Asking it a second way here would let two readers disagree about what `pnpm test`
|
|
20
|
-
* invokes.
|
|
21
|
-
*
|
|
22
|
-
* AN INVOCATION OF MORE THAN ONE TOKEN IS MATCHED ADJACENT AND IN ORDER, which is what lets a
|
|
23
|
-
* caller name a tool AND the command it is being run for. `spec-controller balance` is the
|
|
24
|
-
* reconciler; `spec-controller tags` is the same binary doing something else, and this repository's
|
|
25
|
-
* own pipeline runs both — so a rule comparing the binary alone would take an ordinary step of the
|
|
26
|
-
* pipeline off the books. Per LINE, because two commands on two lines are two commands.
|
|
27
|
-
*
|
|
28
|
-
* Its own module rather than a private helper of the runner rule: the reconciler asks the same
|
|
29
|
-
* question (`parse/reconcilerSteps`), and a second implementation of "does this command run that"
|
|
30
|
-
* is a second chance for the two to answer differently about one step.
|
|
31
|
-
*/
|
|
32
1
|
import { commandInvokesScript } from "./checkScriptsRunInCI.js";
|
|
33
|
-
/**
|
|
34
|
-
* How deep a script-to-script chain is followed before the walk gives up.
|
|
35
|
-
*
|
|
36
|
-
* THREE RATHER THAN UNBOUNDED, and the number is a judgement stated once. A chain deeper than
|
|
37
|
-
* three hops is not a shape any pipeline in the portfolio has, and the manifest being walked was
|
|
38
|
-
* written by the consumer — an input this tool does not control, so it does not walk it without a
|
|
39
|
-
* bound.
|
|
40
|
-
*
|
|
41
|
-
* AND IT IS THIS BOUND, NOT THE VISITED SET BELOW, THAT MAKES A CYCLIC MANIFEST TERMINATE —
|
|
42
|
-
* measured rather than reasoned: deleting the visited set leaves every arm of this rule green,
|
|
43
|
-
* because a chain that loops back exhausts the depth exactly as a long one does. The set is kept
|
|
44
|
-
* because the technical design names it and because it stops a manifest whose scripts cite each
|
|
45
|
-
* other being re-tread inside that budget; what it cannot do is change an answer, so no arm reds
|
|
46
|
-
* on its removal. Said out loud because a comment claiming a guarantee its code does not hold is
|
|
47
|
-
* the kind of thing nothing typechecks.
|
|
48
|
-
*/
|
|
49
2
|
const SCRIPT_CHAIN_DEPTH = 3;
|
|
50
|
-
|
|
3
|
+
// Edge whitespace leaves an empty token, which no invocation token equals.
|
|
51
4
|
function tokenLinesOf(command) {
|
|
52
|
-
return command
|
|
53
|
-
.split(/\r?\n/)
|
|
54
|
-
.map((line) => line.trim().split(/\s+/).filter((token) => token !== ""));
|
|
5
|
+
return command.split(/\r?\n/).map((line) => line.split(/\s+/));
|
|
55
6
|
}
|
|
56
|
-
/** Do these tokens occur, in this order and adjacent, among a line's? */
|
|
57
7
|
function lineRuns(line, invocation) {
|
|
58
8
|
return line.some((_, at) => invocation.every((token, i) => line[at + i] === token));
|
|
59
9
|
}
|
|
60
|
-
|
|
61
|
-
function runs(command, invocation, scripts, depth, visited) {
|
|
10
|
+
function runs(command, invocation, scripts, depth) {
|
|
62
11
|
if (tokenLinesOf(command).some((line) => lineRuns(line, invocation)))
|
|
63
12
|
return true;
|
|
64
13
|
if (depth === 0)
|
|
65
14
|
return false;
|
|
66
|
-
return Object.entries(scripts).some(([name, body]) =>
|
|
67
|
-
commandInvokesScript(command, name) &&
|
|
68
|
-
runs(body, invocation, scripts, depth - 1, new Set([...visited, name])));
|
|
15
|
+
return Object.entries(scripts).some(([name, body]) => commandInvokesScript(command, name) && runs(body, invocation, scripts, depth - 1));
|
|
69
16
|
}
|
|
70
|
-
/**
|
|
71
|
-
* Does this command run the named invocation — itself, or through the manifest scripts it invokes?
|
|
72
|
-
*
|
|
73
|
-
* AN INVOCATION OF NO TOKENS RUNS NOWHERE, which is the guard rather than a formality: an empty
|
|
74
|
-
* token list occurs at every position of every command, so a reader taking it as a match would
|
|
75
|
-
* recognise every step of every pipeline it was handed. A caller that has been told no invocation
|
|
76
|
-
* has been told nothing, and nothing is what it gets back.
|
|
77
|
-
*/
|
|
78
17
|
export function commandRuns(command, invocation, scripts) {
|
|
79
|
-
const
|
|
80
|
-
return
|
|
18
|
+
const text = invocation.trim();
|
|
19
|
+
return text !== "" && runs(command, text.split(/\s+/), scripts, SCRIPT_CHAIN_DEPTH);
|
|
81
20
|
}
|
|
82
21
|
//# sourceMappingURL=commandRuns.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"commandRuns.js","sourceRoot":"","sources":["../../src/parse/commandRuns.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"commandRuns.js","sourceRoot":"","sources":["../../src/parse/commandRuns.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAEhE,MAAM,kBAAkB,GAAG,CAAC,CAAC;AAE7B,2EAA2E;AAC3E,SAAS,YAAY,CAAC,OAAe;IACnC,OAAO,OAAO,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,CAAC;AACjE,CAAC;AAED,SAAS,QAAQ,CAAC,IAAuB,EAAE,UAA6B;IACtE,OAAO,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,EAAE,EAAE,CAAC,UAAU,CAAC,KAAK,CAAC,CAAC,KAAK,EAAE,CAAC,EAAE,EAAE,CAAC,IAAI,CAAC,EAAE,GAAG,CAAC,CAAC,KAAK,KAAK,CAAC,CAAC,CAAC;AACtF,CAAC;AAED,SAAS,IAAI,CACX,OAAe,EACf,UAA6B,EAC7B,OAAyC,EACzC,KAAa;IAEb,IAAI,YAAY,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,QAAQ,CAAC,IAAI,EAAE,UAAU,CAAC,CAAC;QAAE,OAAO,IAAI,CAAC;IAClF,IAAI,KAAK,KAAK,CAAC;QAAE,OAAO,KAAK,CAAC;IAC9B,OAAO,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC,IAAI,CACjC,CAAC,CAAC,IAAI,EAAE,IAAI,CAAC,EAAE,EAAE,CACf,oBAAoB,CAAC,OAAO,EAAE,IAAI,CAAC,IAAI,IAAI,CAAC,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,KAAK,GAAG,CAAC,CAAC,CACpF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,WAAW,CACzB,OAAe,EACf,UAAkB,EAClB,OAAyC;IAEzC,MAAM,IAAI,GAAG,UAAU,CAAC,IAAI,EAAE,CAAC;IAC/B,OAAO,IAAI,KAAK,EAAE,IAAI,IAAI,CAAC,OAAO,EAAE,IAAI,CAAC,KAAK,CAAC,KAAK,CAAC,EAAE,OAAO,EAAE,kBAAkB,CAAC,CAAC;AACtF,CAAC"}
|