feat: support running vale locally

[mdelapenya]

• chore: add a make goal to run the validations
• feat: add a make goal to run vale locally

Description

This PR adds two Make goals:

• make vale, which runs vale as a container using the official Vale Docker image.
• make validate, which runs docker buildx bake validate

The first one allows contributors to detect grammar errors while working on their changes, and the second is an alias for the build command.

The intention here is to enhance the local development experience when contributing to the docs, not having to wait for the CI to understand the vale errors, but instead making it possible to run it locally.

Reviews

• Technical review
• Editorial review
• Product review

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	bce89cf
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/67d01792d314e10008ea5a6f
😎 Deploy Preview	https://deploy-preview-22130--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[craig-osterhout]

Would it make sense to implement this just as bake, or reimplement everything else as make? I mean, why even have bake if make is better, or vice versa?

[crazy-max]

Can we move to another PR the change related to new validate make goal? Doesn't relate to "feat: support running vale locally" and we should not enumerate unrelated change requests in the same PR tbh.

[crazy-max]

I was wondering if we could have it running within our Dockerfile so it could be used with bake like lint:

• docs/docker-bake.hcl

  Lines 48 to 52 in 9623874

  	target "lint" {
  	target = "lint"
  	output = ["type=cacheonly"]
  	provenance = false
  	}

• docs/Dockerfile

  Lines 53 to 60 in 9623874

  	# lint lints markdown files
  	FROM davidanson/markdownlint-cli2:v0.14.0 AS lint
  	USER root
  	RUN --mount=type=bind,target=. \
  	/usr/local/bin/markdownlint-cli2 \
  	"content/**/*.md" \
  	"#content/manuals/engine/release-notes/*.md" \
  	"#content/manuals/desktop/previous-versions/*.md"

Then we could just add a vale bake target to validate group?

docs/docker-bake.hcl

Lines 38 to 40 in 9623874

	group "validate" {
	targets = ["lint", "test", "unused-media", "test-go-redirects", "dockerfile-lint", "path-warnings"]
	}

And would probably be able to remove this ci job

docs/.github/workflows/build.yml

Lines 77 to 86 in 9623874

	vale:
	if: ${{ github.event_name == 'pull_request' }}
	runs-on: ubuntu-24.04
	steps:
	- uses: actions/checkout@v4
	- uses: errata-ai/vale-action@reviewdog
	env:
	PIP_BREAK_SYSTEM_PACKAGES: 1
	with:
	files: content

And just add vale to this matrix

docs/.github/workflows/build.yml

Lines 93 to 99 in 9623874

	target:
	- lint
	- test
	- unused-media
	- test-go-redirects
	- dockerfile-lint
	- path-warnings

so we have a good sandbox that work both on ci and locally?

[mdelapenya]

I still need to create a foundational knowledge on bake, but it seems reasonable to include the target as part of the current build system. I'd go with what you suggest