Add changelog/comment composite and release-notes-comments reusable workflow

[Mpdreamz]

Repos using changelog-validate now upload a changelog-decision artifact on every PR run. Repos that want the sticky PR comment opt in by copying one workflow_run trigger workflow that calls the new release-notes-comments.yml reusable workflow.

Affects: Release notes, Automation

Why

validate-labels and evaluate-pr in docs-builder now write a decision-metadata file on CI (merged in elastic/docs-builder#3993). The metadata travels across the workflow_run boundary as an artifact so a job with pull-requests: write can post the comment without the triggering event needing write access. Fork PRs have the same problem: GitHub forces the token read-only on pull_request from a fork, so commenting must happen in a separate workflow_run job. This PR is the docs-actions half — it uploads the artifact and provides the comment composite and reusable workflow.

What

Fork-context flags passed to evaluate-pr

The changelog/validate composite gains four new env vars (IS_FORK, MAINTAINER_CAN_MODIFY, HEAD_REPO, computed from pull_request event fields) and maps them to --is-fork, --can-commit, --maintainer-can-modify, --head-repo flags. can-commit is true for same-repo PRs; for forks it requires maintainer_can_modify. These fields travel into metadata.json so the comment renderer can choose the right guidance variant.

Artifact upload in changelog/validate

A new Upload decision artifact step runs if: always() at the end of the composite, uploading .artifacts/changelog-decision as changelog-decision with one-day retention and if-no-files-found: ignore. The if: always() means a failing gate (missing label) still uploads — the comment job needs the metadata to explain what is missing.

changelog/comment composite

Downloads changelog-decision cross-run using github.event.workflow_run.id, sets up docs-builder, and runs changelog github-comment --metadata /tmp/changelog-decision/metadata.json. Follows the same check-then-download guard as vale/report to handle cancelled upstream runs gracefully.

release-notes-comments.yml reusable workflow

Triggered via workflow_call (callers use workflow_run on their upstream workflows). Runs the changelog/comment composite with pull-requests: write and contents: none. Concurrency is keyed on the repo + branch with cancel-in-progress: false — two upstream workflows can land close together, and cancelling mid-upsert risks leaving the wrong comment body.

Verify

Copy this trigger workflow into a test repo's default branch and open a PR with no changelog type label:

# .github/workflows/release-notes-comments.yml
name: Changelog PR comments

on:
  workflow_run:
    workflows: ["Release notes"]
    types: [completed]

jobs:
  comment:
    uses: elastic/docs-actions/.github/workflows/release-notes-comments.yml@main
    permissions:
      pull-requests: write

A sticky ### 📋 Changelog comment should appear on the PR naming the missing label. Adding the label and pushing should edit the same comment to the resolved body.

Stack: 2 of 4, on top of elastic/docs-builder#3993. PR 3 strips the JS from submit/apply (coordinated with elastic/cloud). PR 4 drops should-comment-success / should-comment-failure from docs-builder.

Out of scope: changelog/submit is not touched. submit/apply still posts via its existing JS steps. The two implementations converge on one comment during the overlap window — the sticky-comment identity guarantee (marker at end, ### 📋 Changelog prefix first) was established in PR 1.