chore(deps): update dependency fallow-rs/fallow to v3.27.0 - #1758
Merged
Merged
Conversation
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.
This PR contains the following updates:
v3.26.0→v3.27.0v3.28.0Release Notes
fallow-rs/fallow (fallow-rs/fallow)
v3.27.0: : every CI gate can fail the job, baseline staleness in CI, gate results in MCPCompare Source
Features
gate_outcomes, an object keyed by gate name. Each entry hasstatus(pass,warn,failorskipped) andenforced. Where a comparison happened, you also getobserved,thresholdandthreshold_label. Only the gates the run armed appear in the object. Adead-coderun can exit 1 on the default severity rules with no object at all. The key set is open, and a gate name you do not recognise means "some gate". (#2680, #2681, #2683, #2685)--fail-on-stale-baselineon stderr only, and--quietremoves that output. The GitHub Action and the GitLab template both run with--quiet.dead-code/check, the bare run,dupesandhealthreport onebaseline_stalenessobject, in grouped output too. It holds the entry counts,change_scoped, the warning result andgate_trips. Both integrations show a stale baseline as a warning and in the job summary. On a pull request the main run covers changed files only. The integrations therefore re-read the baseline once over the whole project. That re-read took 0.11s with a cache and 0.24s with type-aware analysis on an 870-file TypeScript project. Whether a stale baseline fails the job depends on the newfail-on-stale-baselineinput and theFALLOW_FAIL_ON_STALE_BASELINEvariable. The pull-request comment and the merge-request note do not include the warning yet. Thanks @cloud-walker for the report, which traced the gap through the action scripts. (#2673)min-scoreis an Action input and a GitLab variable. Before this release you could set it only throughargs:/FALLOW_ARGS.--min-scoreimplies--score, so the integrations add--complexitywhen no health section input is set. That keeps the annotations, the SARIF upload and the pull-request comment populated. The CLI turns its own findings rule off for such a run, and the integrations do the same, which leaves the decision to the score.min-scoreandmin-severityapply tocommand: healthand exit 2 elsewhere. (#2682)fail-on-empty-analysis: true(FALLOW_FAIL_ON_EMPTY_ANALYSISon GitLab) makes it fail. The JSON output has ano-source-files-analyzeddiagnostic and the newworkspace_diagnostics[].degrades_analysisfield. When findings cover less than the whole project, the integrations print one combined warning with the diagnostic kinds and their counts. (#2686)--quietand turn exit 1 into a successful result, which hid every gate result from the agent. The rootwarningsarray reports a stale baseline together with the re-save remedy. It also lists every gate that concludedfailorwarn, with its numbers. A run that covered less than the whole project gets one entry too. The subprocess, Code Mode and typed routes all do this.find_dupeswith athresholdtakes the route that can evaluate it. A response with nothing to report is unchanged. (#2676)fallow report --fromshows the gate results in CI. It prints them as a notice annotation and as a line in the job summary, the pull-request comment and the merge-request note. The line is informational and never fails a step. (#2684)Changed
security-gatefails the job independently offail-on-issues. In both integrations the security branch sat inside thefail-on-issuesconditional, andfail-on-issues: falsemeant that branch never ran.Check thresholdstep is gone. Its logic moved into the analyze step, and thegates-failedoutput names the gates that decided the result.enforced: falsefor it. Standalonedupesexits 1 as before. The default GitLab job forwards the threshold in combined mode, and that pipeline prints a warning with the reason.--fail-on-stale-baselinechanges one field in the output. That field isgate_outcomes["stale-baseline"].enforced. Nothing inbaseline_stalenessdepends on the flag, not evengate_trips.health --report-onlysetsenforced: falseon every gate it evaluated.fallow reportdescribes the scoped run, where the gate fails nothing.schema_versionin the JSON output changed.gate_outcomesandworkspace_diagnostics[].degrades_analysisare additive and optional.Bug fixes
fail-on-regression,threshold,min-severityand the security gate fail the job. All four were documented as gates. Each one reported its result on stderr, which--quietremoves. Both integrations also drop the exit code when stdout parses as JSON. The integrations readgate_outcomesinstead. A gate fails the build when itsstatusisfailandenforcedis true, and only when the input that owns it was set. A flag passed throughargs:prints a warning and cannot overridefail-on-issues: false. (#2680, #2681, #2683, #2685)thresholdapplies to the bare command on GitHub. The Action forwarded it oncommand: dupesonly.Upgrade notes
fail-on-regression,threshold,min-severityor a security gate and relied on the job passing, expect failures. Withsecurity-gateandfail-on-issues: false, unsetsecurity-gateto keep the old behaviour.--fail-on-stale-baselinefromargs/FALLOW_ARGS, delete any separate unscoped gate step added as a workaround, and set thefail-on-stale-baselineinput.fail-on-stale-baselinewith nobaselineset, or onfixorsecurity, exits 2.baselineandsave-baselineat the same file. The run saves before it compares, and such a baseline can never have a stale entry. The integrations warn about it.Check thresholdstep by name (continue-on-error,steps.*.outcome), point it at the analyze step and thegates-failedoutput.npm/fallow/typesin TypeScript,HealthBaselineStalenessis nowBaselineStaleness. The old name remains as a deprecated alias.Full Changelog: fallow-rs/fallow@v3.26.0...v3.27.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.