report-failure.yml

# Copy the `report-failure` job below into a workflow whose failures you want
# tracked as an issue -- it is a job to add to an existing caller stub, not a
# workflow to install on its own.
#
# NOTE: Do NOT name a `concurrency:` group `gh-pages` anywhere in this
# caller workflow -- neither a top-level block nor one on the calling job,
# which deadlock identically
# ([gha#811](https://github.com/Morrison-Lab/gha/pull/811)).
# Any OTHER group name is fine,
# and is how you serialize this workflow's own runs.
# The `quarto-publish.yml` it calls serializes gh-pages
# deploys internally on its `deploy` job (`group: gh-pages`). A caller-level
# block with the same group name deadlocks GitHub Actions against the nested
# job: the job fails with no runner, no steps, and no log, so the site
# silently stops publishing
# ([gha#809](https://github.com/Morrison-Lab/gha/issues/809)).
#
# It exists for workflows that run where no pull request carries their result:
# a push to the default branch, a schedule, a release. There, a failed run
# shows up only in the Actions tab, so a broken deploy can go unnoticed while
# the published site goes stale.
#
# Repeat failures comment on the issue already open for that title instead of
# filing another, so leave `title` fixed and close the issue once the workflow
# is green again.
name: Quarto Publish

on:
  push:
    branches: [main]
  workflow_dispatch:

# Serialize deploys so two pushes don't race on the gh-pages branch. Named
# for this workflow rather than `gh-pages`, which the called
# quarto-publish.yml's own deploy job already holds -- reusing that name
# deadlocks the two, per the NOTE at the top.
concurrency:
  group: quarto-publish-${{ github.ref }}
  cancel-in-progress: false

jobs:
  publish:
    permissions:
      contents: write
    uses: Morrison-Lab/gha/.github/workflows/quarto-publish.yml@v2
    with:
      path: website

  report-failure:
    needs: publish
    # `always()` is what lets this job run at all once `publish` failed; the
    # result check is what decides.
    #
    # The `pull_request` clause is inert as this stub stands, since the
    # triggers above are push and dispatch only. Keep it if you add a
    # `pull_request` trigger (a render-only build check, say): a PR shows its
    # own failure on the PR, so filing an issue for it is noise.
    if: >-
      always()
      && needs.publish.result == 'failure'
      && github.event_name != 'pull_request'
    permissions:
      # Only this job needs it, which is why failure reporting is a separate
      # workflow rather than a job inside quarto-publish.yml: a caller must
      # grant a reusable workflow's permissions, so folding it in would make
      # `issues: write` mandatory for everyone calling that workflow.
      issues: write
    uses: Morrison-Lab/gha/.github/workflows/report-failure.yml@v2
    with:
      # Stable across runs -- this is the deduplication key.
      title: Publish workflow is failing
      body: The documentation site did not deploy, so the published site may be stale.
      # labels: bug,automated      # must already exist in your repo to be applied