Skip to content

translation-status: a generated-page plugin can pin the job red with no way out #44

Description

@mairas

The anchor step hard-codes check-anchors site — no --exclude, no site
directory override — and the workflow exposes one input, runs-on.

halos-org/docs already runs mkdocs-print-site-plugin, whose single-page
export accounts for 690 broken fragments there while the content pages are
clean; the documented remedy is --exclude 'print_page/*'. A translated docs
repo that adds the same plugin gets a red job on every pull request and every
push, for something no author can fix in content.

The escape routes are: fork the workflow, remove the plugin, or stop requiring
the check. The third is cheapest, and because the anchor check and the
translation gate share one job, it disables the gate this workflow exists to
add.

Same shape for site_dir. The README lists "leaves site_dir at its default"
as an unvalidated requirement; a consumer that changes it gets check-anchors
exit 2 on every run.

Two candidate fixes, not exclusive:

  1. Add anchor-exclude and site-dir inputs, defaulted to today's behaviour.
    Additive, breaks nobody.
  2. Split the site build and anchor check into their own reusable workflow, so
    disabling one does not disable the other — and so a monolingual docs repo can
    call the anchor check without writing it by hand, which today it must.

Both were raised on #39,
by the adversarial and maintainability reviewers respectively. Deliberately not
done there: the first consumer needs neither, and inputs are additive later.
Worth settling before a second consumer is wired.

See also halos-org/docs-tools#9
for reading site_dir from mkdocs.yml, which would remove half of this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions