Topic docs ci markdownlint

[vanshika2720]

Description

This PR introduces:

markdownlint-cli2

for PipeCD developer documentation in a non-disruptive and incremental way.

The workflow adds automated Markdown linting for:

docs/content/en/docs-dev/**/*.md

to help catch common documentation issues such as:

• Invalid heading structure
• Unclosed code fences
• Broken list formatting
• General Markdown structural inconsistencies

before changes are merged.

The initial configuration intentionally relaxes several noisy legacy and Hugo-incompatible rules to avoid large-scale formatting churn across the existing documentation while still establishing a strong CI foundation for future incremental documentation quality improvements.

---

Changes Proposed

GitHub Actions Workflow

Added:

.github/workflows/docs-lint.yaml

Workflow behavior

The workflow:

• Runs on pull requests affecting documentation-related files
• Sets up Node.js
• Installs markdownlint-cli2
• Executes Markdown linting against developer documentation files

Target scope:

docs/content/en/docs-dev/**/*.md

---

Markdownlint Configuration

Added:

.markdownlint-cli2.yaml

Configuration goals

The configuration is designed to:

• Relax legacy formatting-heavy rules
• Preserve compatibility with existing Hugo documentation patterns
• Avoid large-scale repository-wide formatting rewrites
• Enable gradual adoption of Markdown linting standards

---

Temporarily relaxed rules

Examples include:

• MD013 — line length
• MD033 — inline HTML
• MD040 — fenced code language

This keeps the rollout practical while still enforcing:

• Structural correctness
• Markdown integrity
• Consistent formatting foundations

---

Verification

Verified locally using:

markdownlint-cli2 "docs/content/en/docs-dev/**/*.md"

Output

Linting: 78 file(s)
Summary: 0 error(s)

---

Why this is valuable

This improves documentation DX by:

• Introducing automated Markdown validation in CI
• Reducing reviewer overhead for structural Markdown issues
• Catching formatting and rendering problems earlier
• Establishing scalable documentation quality standards

This also prepares the documentation system for:

• Larger documentation initiatives
• Community-driven contributions
• Developer-facing technical guides
• Plugin and architecture documentation expansion

---

Safety

This PR only introduces:

• CI workflow automation
• Markdown linting configuration

It does not affect:

• Runtime behavior
• Backend logic
• Deployment functionality
• Documentation rendering architecture

No production application behavior is modified.

[vanshika2720]

@rahulshendre @khanhtc1202 @eeshaanSA

[mohammedfirdouss]

why do we need this?