| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 9ad380fb7a1b122a605c7562124085e3200e30f0)
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
* DOCS: Backport 2117 (Revise Console server page) to Circinus
* Update console-server.md
|
|
* docs: Update TFTP server page to VyOS 1.5 standards
* Update tftp-server.md
(cherry picked from commit 8be9ced92fdc2b12b16aae9e438884acfd387faf)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
* configexamples/inter-vrf-routing-vrf-lite: fix formatting
* configexamples/inter-vrf-routing-vrf-lite: reformat text to limit line length
|
|
* docs: Update Config sync page to VyOS 1.5 standards
* Minor corrections
* Update config-sync.md
* Apply suggestion from @github-actions[bot]
* Apply suggestion from @github-actions[bot]
---------
(cherry picked from commit 228149f1a1d824b968b565f82c3ee73eb7ba489c)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
|
(#2108) (#2109)
On a fresh (no-consent) load the consent banner could render completely
unstyled and expand to full page height. Cookiebot delivers its dialog CSS as
a constructed stylesheet on document.adoptedStyleSheets; ReadTheDocs'
readthedocs-addons.js reassigns that whole-array property with a destructive
replace, and when that lands after Cookiebot's network-gated adoption it drops
Cookiebot's sheet, leaving #CybotCookiebotDialog at position:static expanded to
~6700px. It is a race, so it is intermittent and clears once consent is given
(the dialog then never renders).
- layout.html: a small adoptedStyleSheets shim, installed before any page
script, that preserves Cookiebot's sheet so another library cannot drop it.
- custom.css: a leak-safe safety net that keeps the dialog contained even if
its adopted sheet is ever absent. It uses only properties Cookiebot itself
sets, so it has verifiably no effect on the normal, styled banner.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit dce7bb521e3947af59fe18895b609ec353e0450e)
Co-authored-by: Yuriy Andamasov <yuriy@vyos.io>
|
|
docs: fix local syslog command syntax for 1.5 (T8983)
|
|
|
|
|
|
(β¦" (#2095)
This reverts commit 6b88b233b56e7231fbdf0ed4644f741cf634b9ba.
|
|
* docs: Update RPKI page to VyOS 1.5 standards
* Update rpki.md
* Update rpki.md
(cherry picked from commit 5d631ab0628d6b3266b14a7d25ad9e7b66035636)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
* docs: Update Traffic Engineering page to VyOS 1.5 standards
* Update traffic-engineering.md
* Update traffic-engineering.md
(cherry picked from commit 361ea4841449956af979eb24a0b4e2f869d6ebf2)
# Conflicts:
# docs/configuration/protocols/traffic-engineering.md
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
* docs: Update Segment Routing page to VyOS 1.5 standards
* docs: Minor corrections
* docs: Minor formatting corrections
* Update segment-routing.md
(cherry picked from commit f01638d2e6ac85b0096a0895635c325569a7771a)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
* docs: Update RIP page to VyOS 1.5 standards
* Update rip.md
(cherry picked from commit b8a4d737a86015606a1faf0ab49b631db02448b2)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
* docs: Update MPLS page to VyOS 1.5 standards
* Update mpls.md
(cherry picked from commit b02ee21632e7097bc1408388bdfd99f84f8e7771)
Co-authored-by: LiudmylaNad <l.nadolina@vyos.io>
|
|
(cherry picked from commit 875b0825b24c03b9a5ba904f8f2d2de946564b74)
Co-authored-by: Nataliia Solomko <natalirs1985@gmail.com>
|
|
centrally) (#2084)
|
|
high-availability: T7059: Add persistence-timeout option in virtual-server (backport #2053)
|
|
bgp: T8607: Add CLI support for BGP update-delay and establish-wait (backport #1891)
|
|
conntrack: T8308: Enhancements to the `show conntrack table` op-mode command (mirror 2055) (backport)
|
|
- Display per-flow packet and byte counters (original and reply
direction).
- Add VRF filter option `show conntrack table <ipv4|ipv6> vrf <vrf-name>`.
(cherry picked from commit 447b0bd6e804896506d3eb65f01856f82c8b9af7)
|
|
T8960: ai-validation β consolidate cross-repo auth onto vyos-bot App (backport #2077)
|
|
Swap the cross-repo-checkout token from the dedicated vyos-docs-reviewer
App (VYOS_APP_ID/_PRIVATE_KEY) to the shared vyos-bot App via the fleet
get-token composite, scoped contents:read. Skip-check now gates on
APP_CLIENT_ID + APP_PRIVATE_KEY + ANTHROPIC_API_KEY (org-level vyos-bot
creds); reword the stale token comment. PR-comment posting still uses
the default GITHUB_TOKEN. Byte-identical to the paired reference copy in
VyOS-Networks/vyos-docs-opus-reviewer (scripts/ai-validation.yml).
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 459109f13adf026d012c4e803f4a86a8f84e6ce3)
|
|
* bgp: T8607: Add CLI support for BGP update-delay and establish-wait
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* T8607: Apply Copilot's suggestions
---------
Co-authored-by: Christian Breunig <christian@breunig.cc>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
(cherry picked from commit 65a5a35942c099f337ef4224251bbbaf8e076dbb)
|
|
(cherry picked from commit dc04c30291806195311e585450b490d0c672c356)
|
|
ci(ai-validation): allow Pass 2 review on external-contributor PRs (backport #2063)
|
|
The upstream `anthropics/claude-code-action` performs a write-permission
check on `github.actor` before our skip logic runs. On `pull_request_target`
the actor is the PR author; external contributors resolve to `read` and the
action exits 1 with `Actor does not have write permissions to the repository`.
Net effect: AI validation has been failing on every external-contributor PR
(LiudmylaNad, teslazonda, scottlaird in the last 4 weeks) while succeeding
on maintainer PRs. Failure reproduced on run 26541079685 (PR #2061).
Fix: set `allowed_non_write_users: '*'` on the Pass 2 step. The action
bypasses the actor check when this input is set and `github_token` is
provided (already the case). The action also auto-scrubs Anthropic / cloud
/ GHA secrets from subprocess envs when this input is set.
Safe in THIS workflow because the existing defense-in-depth bounds what
Pass 2 can do with untrusted PR content:
- `allowedTools` restricted to inline-comment + read-only surfaces
- `github_token` is the PR-scoped default (not the broader VYOS_APP_ID)
- prompt marks PR content as untrusted via `<UNTRUSTED-PR-CONTENT>`
- workspace-wipe removes `CLAUDE.md` / `.claude/` before Pass 2
- prepare bundles MD via `git show HEAD:<path>` (blob, not `cp`)
Full rationale inlined as a comment block above the new input.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 1fa39bd7ac64898f7a21922bc0f195d115d3cdeb)
|
|
ci(ai-validation): skip prepare on Mergify-authored PRs (backport #2043)
|
|
Lifts the existing Mergify-author short-circuit (today inside validate's
`secrets-check` step) to a job-level `if:` on `prepare`, so the whole
pipeline skips for backport/queue PRs.
Why now: every Mergify backport whose merge ref shares no shallow
ancestor with the (advanced) base branch fails the prepare step at
git diff "$BASE...HEAD" --name-only ...
fatal: FETCH_HEAD...HEAD: no merge base
(because base is `git fetch --no-tags --depth=1` and the merge ref is
`fetch-depth: 2`). Proximate symptom: run 25842928620 on PR #2042
(sagitta backport of #2023). AI Validation isn't a required check so
the queue isn't blocked, but every Mergify backport is left with a red
"prepare" check that adds noise to PR review.
The validate-level skip in commit 0e8a2956 was correct for the
"claude-code-action rejects bot-initiated runs" failure mode but
fires too late β prepare has already run and crashed before validate's
`if: needs.prepare.outputs.has_md_changes == 'true'` even evaluates.
Implementation: single job-level `if:` on prepare. validate's
`needs: [prepare]` cascades the skip naturally (skipped needs make
the dependent's expression-based `if:` evaluate against empty outputs).
The in-step author check in validate stays as defense-in-depth.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 7d94d6116be1a4776b7317cb5190a83dd065e571)
|
|
ci(doc-linter): fix 12 accumulated bugs flagged across PR #2014/#2019/#2020 reviews (backport #2023)
|
|
Addresses Copilot review on PR #2023:
1. .. code-block:: tracking was triggered by a plain substring check, which
matched mid-line occurrences too. In MD prose like ``.. code-block::``
(docs/documentation.md:222) this set in_rst_codeblock=True spuriously and
could suppress line-length checks downstream. Replace with a leading-whitespace-
anchored regex and gate on file_ext in ('.rst', '.txt') or an open {eval-rst}
MyST fence so the directive opener is only recognized where it can actually
occur.
2. print('start') in main() was leftover debug noise β remove it.
(cherry picked from commit e87278ef35660a6257b55f4585274a52d3124583)
|
|
removal with word-boundary prefix
Agent-Logs-Url: https://github.com/vyos/vyos-documentation/sessions/cdefcaf2-e89e-4090-b39a-15b385b774df
Co-authored-by: andamasov <12631358+andamasov@users.noreply.github.com>
(cherry picked from commit be8090a3a09adb950557c2887c9a27c017ffd31d)
|
|
Each `uses:` line was pinned to a mutable version tag (`@v6`,
`@v0.8.4`, β¦). Tags can be rewritten to point to malicious code β
CVE-2025-30066 (reviewdog/action-setup) and the tj-actions/changed-files
incident in 2025 are the canonical real-world examples. GitHub's
hardening guide for Actions recommends pinning to full-length commit
SHAs and keeping the tag as a trailing comment for human readability.
Resolved each action's tag to its commit SHA via `gh api
/repos/<repo>/git/refs/tags/<tag>` and verified the SHA is a commit
(not an annotated-tag object) via `gh api
/repos/<repo>/git/commits/<sha>`:
- actions/checkout v6 -> de0fac2e4500dabe0009e67214ff5f5447ce83dd
- bullfrogsec/bullfrog v0.8.4 -> 1831f79cce8ad602eef14d2163873f27081ebfb3
- trilom/file-changes-action v1.2.4 -> a6ca26c14274c33b15e6499323aac178af06ad4b
- actions/setup-python v6 -> a309ff8b426b58ec0e2a45f0f869d46889d02405
This change covers `lint-doc.yml` only. A fleet-wide sweep across
every workflow in `.github/workflows/` is a separate effort β
worth doing because the drift / supply-chain risk is the same in
every one. Tracked as a follow-up to this PR's review.
Tracked as item 11 of the rolling-side cleanup backlog from PR #2014
/ #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit e99182b911dbe9d3a3f02e000426f7075cadc608)
|
|
Previous workflow:
env:
FILES_MODIFIED: ${{ steps.file_changes.outputs.files_modified }}
run: python scripts/doc-linter.py "$FILES_MODIFIED"
`trilom/file-changes-action`'s `files_modified` output is
modifications-only. A PR adding a new `.md`/`.rst` doc page passed
`files_added`, never `files_modified`, so a brand-new page with long
lines or real public IPs slipped past the linter entirely.
Workflow: also pass `files_added` and `files_renamed` as separate
positional args. Each output is a JSON array (action v1.2.4) and is
passed via env to avoid shell-quoting issues.
Linter: `main()` now accepts one OR multiple positional argv entries,
each a JSON array of paths. Arrays are merged and deduplicated before
linting. Single-arg invocations remain backward-compatible. Switched
from `ast.literal_eval` to `json.loads` β the action's outputs are
JSON, and `json.loads` is the right tool (and dodges
literal_eval-via-`eval`-substring linter warnings).
Test coverage:
- Two JSON arrays merge -> single linter run on union.
- Empty-string argv entry skipped (no `files_renamed` in many PRs).
- Malformed JSON -> falls back to walking DOCS_ROOT.
- No argv -> walks DOCS_ROOT.
- Single-arg invocation -> backward-compat preserved.
Tracked as item 7 of the rolling-side cleanup backlog from PR #2014 /
#2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 1ef5684729646ca3a24aff83ab8edd0aa57914c7)
|
|
`is_docs_path()` returned True for any path under `docs/`, including
the archived RST shadows under `docs/_rst_legacy/` and the build
output under `docs/_build/`. Sphinx excludes both from the build
(per `docs/conf.py`'s exclude_patterns) and AGENTS marks
`_rst_legacy` as reference-only. The linter shouldn't process either.
Add a `DOCS_EXCLUDED_SUBDIRS = ('_build', '_rst_legacy')` constant.
After confirming a path is under `docs/`, walk each excluded subtree
and reject the path if it's contained.
Also unify the auto-discover walk fallback to call `is_docs_path()`
for the filter β previously it had its own hand-rolled `"_build"
not in path` check that didn't handle `_rst_legacy` at all and would
have walked the entire legacy archive. Prune `dirs[:]` in-place at
each walk level so we don't descend into the excluded subtrees in
the first place β optimization on top of correctness. Reverted the
`_dirs` -> `dirs` rename here because we now mutate it.
Test coverage: 10 hand-coded `is_docs_path()` cases β all pass:
- `docs/configuration/foo.md` -> True
- `docs/_rst_legacy/foo.rst` -> False (was True)
- `docs/_rst_legacy/subdir/rst-foo.rst` -> False (was True)
- `docs/_build/html/index.html` -> False (was True)
- `docs/_include/foo.txt` -> True (live snippets stay in scope)
- `docs` -> True
- `AGENTS.md`, `README.md`, `.github/copilot-instructions.md`,
`scripts/doc-linter.py` -> False (already correct)
Tracked as item 4 of the rolling-side cleanup backlog from PR #2014
/ #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 379ed4757b62a7c1df965a59bc4f1fd0cef2d3e8)
|
|
The line-length skip was
test_line_length = not (in_md_fence or in_rst_codeblock)
`in_md_fence` was True for every MyST/Markdown fence regardless of
content type. That includes admonition directives like `:::{note}`,
`:::{warning}`, `:::{tip}` whose content is normal prose, not
preformatted code. Long lines in admonitions were silently skipped,
contradicting the documented 80-char rule which exempts code blocks
only.
Track an `is_code` property on each fence-stack entry. A fence is
code-bearing when:
- info string is empty (plain ``` per CommonMark), OR
- info string doesn't start with `{` (bare language tag like
`python`, `bash`, `yaml`), OR
- info string is `{<directive>}` and `<directive>` is in the
CODE_BEARING_DIRECTIVES set (`code-block`, `code`, `sourcecode`,
`cfgcmd`, `opcmd`, `cmdinclude`, `cmdincludemd`, `literalinclude`,
`parsed-literal`, `raw`, `command-output`, `eval-rst`).
Anything else is prose-bearing (`{note}`, `{warning}`, `{tip}`,
`{deprecated}`, `{seealso}`, β¦) and its content gets line-length
checked.
`in_md_code_fence` checks the topmost stack entry β the innermost
fence wins, so a `{note}` containing an inner `{code-block}` lints
the outer prose lines and skips the inner code-block body. The
classic `is_suppression_marker()` call still uses `in_md_fence`
because suppression markers are about "any fence depth" not
"code-bearing depth".
`{eval-rst}` is kept in CODE_BEARING_DIRECTIVES to preserve current
behavior β its body is RST and any line-length on nested
`.. code-block::` is handled by the separate RST tracker. Tightening
eval-rst is a separate change if wanted.
Test coverage:
- `_fence_is_code` classifier: 16 cases (code-like vs prose-like)
all pass.
- Integration: long line in `{note}` flagged β; long line in
```python``` not flagged β; long line in `{cfgcmd}` not flagged β;
nested `{note}` > ```text``` β inner skipped β; nested `{note}` >
prose β flagged β.
Sweep over current `docs/` tree: 28 new warnings surface across the
existing pages (long prose inside admonition directives that the
previous logic had been silently hiding). CI on PR scope is changed
files only, so the new findings appear only when contributors touch
those pages β they won't break this PR or future infra PRs.
Tracked as item 5 of the rolling-side cleanup backlog from PR #2014
/ #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit cd5759f26a1c18abc3c137234cf1ab503e2b26b7)
|
|
The dedent check inside `handle_file_action()` was
if in_rst_codeblock:
if len(line) > rst_codeblock_indent and not line[rst_codeblock_indent].isspace():
in_rst_codeblock = False
This worked only when the next line was at least
`rst_codeblock_indent + 1` chars long β the indexing
`line[rst_codeblock_indent]` requires that. A short dedented
line (e.g., a single character at column 0 under a directive
indented at column 4) failed the length guard and `in_rst_codeblock`
stayed True. The block remained open longer than it should,
suppressing line-length checks on subsequent prose until either
EOF or the next `.. code-block::` reset the state.
Replace with a leading-whitespace-count check: on any non-blank
line, exit the block when leading-ws is <= the directive's
column. Blank lines don't reset the block context.
Test: a 3-line file with `.. code-block:: text` directive at col
0, one body line, a single `a` at col 0, then a 113-char line
at col 0. With the old logic the long line is still treated as
inside the code block and not flagged. With the new logic the
single-`a` dedent exits the block and the long line is flagged
as expected.
Tracked as items 6 and 12 of the rolling-side cleanup backlog
from PR #2014 / #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 6628b2901933f67568ba68617ee27c6f843c6dcf)
|
|
The leading-compression group in `IPV6GROUPS` was
r'(?:\s' + IPV6SEG + r':){1,7}:'
The `\s` required whitespace before each hextet in the repeated
group. In practice this meant compressed forms with leading
hextets β `2001:db8::`, `64:ff9b::`, `fe80::1` β only matched
when preceded by whitespace inside the line. The linter calls
`lint_ipv6(line.strip())`, so at start-of-stripped-line there's
no whitespace, and the address fell through to no match.
Real-world impact: a documentation page mentioning
`2001:4860:4860::8888` (Google DNS) or `64:ff9b::1` (NAT64
well-known prefix) at the start of a line silently passed the
IPv6 documentation-address check.
None of the other groups in `IPV6GROUPS` use a `\s` prefix.
This one was inconsistent. Drop the `\s` so the branch matches
compressed forms directly, like its peers.
Verified with 6 hand-coded cases (RFC 3849 doc range, Google
DNS, NAT64 prefix, mid-line and start-of-line positions). All
pass.
Tracked as item 3 of the rolling-side cleanup backlog from PR
#2014 / #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit cc1b4d7c28272786e39a11b37a3ca22b80b12eec)
|
|
`lint_ipv4()` and `lint_ipv6()` used `re.search`, which returns
only the first match. A line like
Set DNS forwarder 192.0.2.1 then fall back to 8.8.8.8
flagged nothing because `192.0.2.1` (RFC 5737 documentation
range) is allowed and the search stopped there. The real
public IP `8.8.8.8` slipped through despite being exactly
the case the linter was meant to catch.
Switch both functions to `re.finditer` and walk every match:
return on the first disallowed address; only return None when
all matches on the line are allowed (private / multicast /
non-global).
Also fix the casing of "private space" in both error
messages β was "private Space" with a stray capital.
Verified with 7 hand-coded cases (allowed + public mixes,
boundary cases, IPv6 RFC 3849 / Google DNS). All pass.
Tracked as items 1, 2, and 10 of the rolling-side cleanup
backlog from PR #2014 / #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 85c0c1ea222d2c70662de5a03ecaf04b6498006e)
|
|
`lint_AS()` and its `NUMBER` regex were a placeholder for a
future AS-number documentation-range check (RFC 5398).
`lint_AS()` was never called from anywhere β it'd merely
`pass` on `re.search` hit. Pure dead code that made it look
like AS-number linting existed when it didn't.
Delete:
- the `NUMBER` regex constant
- the `lint_AS()` function
If/when AS-number linting is actually desired, implement it
properly: hook into the lint loop in `handle_file_action()`,
return the standard `(message, line, severity)` tuple on
violations, and define the allowed AS ranges from
`/^AGENTS.md/` (currently 64496β64511 and 65536β65551).
Tracked as item 8 of the rolling-side cleanup backlog from
PR #2014 / #2019 / #2020 reviews.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit 61ecb4e103c6a6225b3d71586f7f65e41c3e3510)
|
|
`lint_mac()` was called and its return value immediately overwritten
with `None`:
err_mac = lint_mac(cnt, line.strip())
# disable mac detection for the moment, too many false positives
err_mac = None
The comment is correct β MAC linting produced too many false
positives β but the cleanup never landed. The dead call ran on every
line for every linted file, and the function/MAC-regex/MAC-error-text
all sat in the source as a misleading hint that MAC linting was a
live feature.
Delete:
- the `MAC` regex constant
- the `lint_mac()` function
- the `err_mac = lint_mac(...)`, `err_mac = None`, and the `err_mac`
entry in the tuple iterated by the error-collection loop in
`handle_file_action()`
Tracked as item 9 of the rolling-side cleanup backlog flagged across
the PR #2014 / #2019 / #2020 reviews. When MAC linting is genuinely
wanted again, recover the regex/function from git history and wire it
in cleanly.
π€ Generated by [robots](https://vyos.io)
(cherry picked from commit ac9f61e5ae366774e51975b0faddd7ba07996762)
|
|
ci(workflows): remove conflict markers from update-version-tags.yml (circinus)
|
|
`.github/workflows/update-version-tags.yml` has carried literal git
conflict markers in its YAML header since the Mergify auto-backport
in #1988 (cherry-pick of #1984 onto circinus) β the cherry-pick
conflicted, but Mergify's `ignore_conflicts: true` default at the
time committed the markers verbatim into the file. (The central
Mergify config switched to `ignore_conflicts: false` a few days
later as a direct response to this class of incident; #1988 had
already merged.)
Result: GitHub's YAML parser fails on `<<<<<<<` / `=======` /
`>>>>>>>` and the workflow can't schedule any job. Every push to
circinus touching `docs/**` or `context7.json` since #1988 merged
reported "this run likely failed because of a workflow file issue"
with 0 jobs. The downstream `context7-refresh.yml` (which uses
`workflow_run` to react to this workflow's name) also never fired,
so Context7's `1.5` index has been getting stale on every doc push.
Fix: replace the file with rolling's verbatim content. The
post-conflict-marker content on circinus was already byte-identical
to rolling; only the marker block + the obsolete comment block
above it differ. Confirmed with
`diff <(git show origin/rolling:.../update-version-tags.yml) <(...)`
returning empty after stripping markers.
After this merges:
- `Update version tags` runs on every docs-affecting push to
circinus, moves the `1.5` tag to HEAD.
- `Context7 refresh` fires via `workflow_run` and refreshes the
`1.5` index.
π€ Generated by [robots](https://vyos.io)
|
|
Backport [vyos-documentation#2024](https://github.com/vyos/vyos-documentation/pull/2024) to circinus (manual β Mergify cache failure)
|
|
doc-lint regression on [vyos-documentation#2024](https://github.com/vyos/vyos-documentation/pull/2024): the CI workflow's
`scripts/doc-linter.py` scans every line of every changed file
(not just changed lines), so the typo fix on `cli.md:464` and the
capitalization fix on `aws.md:118` surfaced 57 pre-existing >80-char
violations that have lived on rolling since the MyST migration.
`cli.md` β 53 prose paragraphs hard-wrapped at word boundaries to
80 chars, preserving content fidelity. List items use hanging-indent
continuations under their `- ` marker. No content reworded; only
soft-wrap β hard-wrap.
`aws.md` β wrapped the inline AWS GWLB blog link (L164) and the
References section (L185-187) with `% stop_vyoslinter` /
`% start_vyoslinter` markers. These are URL-bearing lines that
cannot be shortened (URL itself >80 chars).
Verified locally:
`python3 scripts/doc-linter.py "['docs/cli.md','docs/installation/cloud/aws.md','docs/automation/terraform/terraformvyos.md']"`
β exit 0, no violations.
π€ Generated by [robots](https://vyos.io)
|
|
The full HashiCorp install-CLI URL is 79 chars, so any reference
definition `[X]: <URL>` form exceeds the 80-char docs-lint limit
regardless of label length. Existing `% stop_vyoslinter` /
`% start_vyoslinter` markers in this file were back-to-back with
no content between them (flagged by Copilot on
[vyos-documentation#2021](https://github.com/vyos/vyos-documentation/pull/2021)) β put them to work by wrapping the long
`[install Terraform]:` reference. The shorter
`[Terraform introduction]:` reference (73 chars) sits outside the
suppression range.
Both Copilot and CodeRabbit flagged the docs-lint regression on
[vyos-documentation#2024](https://github.com/vyos/vyos-documentation/pull/2024) β verified locally with
`python3 scripts/doc-linter.py docs/automation/terraform/terraformvyos.md`:
no warnings.
π€ Generated by [robots](https://vyos.io)
|
|
Surfaced by CodeRabbit on the circinus RSTβMD conversion PR
[vyos-documentation#2021](https://github.com/vyos/vyos-documentation/pull/2021) (`terraformvyos.md:14`). Both labels violate MD059
(descriptive link text) β generic words like "link" don't convey
the destination to screen-reader users or search indexers.
Pre-existing on rolling; out of scope for the conversion port,
fixed here at the source. Mergify will backport to circinus and
sagitta. Sibling `automation/terraform/index.md` already uses the
descriptive form ([Terraform], [Ansible]).
π€ Generated by [robots](https://vyos.io)
|
|
Three pre-existing rolling docs bugs, surfaced by Copilot review on
the sagitta RSTβMD conversion PR #2022 against the byte-for-byte
ports of `cli.md` and `aws.md`:
- `cli.md` line 464: `set interface ethernet β¦` is wrong; the CLI
command is `set interfaces ethernet β¦` (plural). Users copying the
example verbatim would hit "Configuration path is not valid".
- `cli.md` lines 527-528: orphan `:::` / `::::` fence closers after
the `{cfgcmd} save` block. The `(save)=` directive opens at line
503 and closes at line 506; the two `` ``` none `` blocks at
508-526 are self-contained; nothing opens these colon fences.
MyST/Sphinx tolerates them silently today but they're literal
noise. Drop both.
- `aws.md` line 118: "Cloudwatch" β "CloudWatch", matching the
surrounding correctly-cased uses on lines 115/121/122 and AWS's
product naming.
Mergify will backport to circinus and sagitta via the standard
`@Mergifyio backport circinus sagitta` post-merge.
π€ Generated by [robots](https://vyos.io)
|
|
docs(circinus): finish RSTβMD conversion β drop changelog, port terraformvyos
|
|
fix(includes): rewrite need_improvement.txt as MyST so plain `{include}` renders correctly (backport #2016)
|
