Ship markfluence as a reusable GitHub Action

Let this repo double as a GitHub Action so downstream repos can publish markdown to Confluence from CI (e.g. on push to docs/**), e.g. uses: mozilla/markfluence@v1. The repo can be both the CLI source and the action — an action.yml at the repo root coexists with the Go module.

Recommended approach: composite action

Author action.yml with runs.using: composite whose steps download the goreleaser release binary for the runner's OS/arch and invoke it. We already publish markfluence_<version>_<os>_<arch>.tar.gz for darwin+linux × arm64+amd64, so the action just fetches the matching asset and runs it.

• Fast (no image build), works on Linux and macOS runners, reuses existing releases.

Sketch

# action.yml
name: markfluence
description: Publish markdown to Confluence
inputs:
  command:  { description: "update | create | fix", required: true }
  files:    { description: "markdown files/globs", required: true }
  url:      { description: "Confluence base URL", required: true }
  username: { description: "Confluence username/email", required: true }
  version:  { description: "release tag to use", default: latest }
runs:
  using: composite
  steps:
    - shell: bash
      run: |  # download markfluence_<ver>_<os>_<arch>.tar.gz, extract, then:
        markfluence "${{ inputs.command }}" ${{ inputs.files }} \
          --url "${{ inputs.url }}" --username "${{ inputs.username }}"

Consumer:

- uses: mozilla/markfluence@v1
  with: { command: update, files: "docs/*.md", url: https://org.atlassian.net, username: bot@org.com }
  env:  { CONFLUENCE_TOKEN: ${{ secrets.CONFLUENCE_TOKEN }} }

The CLI already reads CONFLUENCE_TOKEN only from the environment (never a flag), so the token stays a secret env var and never becomes an action input.

Alternatives considered

• Docker container action (runs.using: docker): self-contained but Linux-only and slower cold start; unnecessary since we ship static binaries.
• JS/TS action: not a fit for a Go CLI without a wrapper.

Work / open questions

• Add action.yml (composite) that resolves version (default latest), downloads the correct release asset, verifies it, and runs the requested subcommand.
• Map inputs → flags; pass CONFLUENCE_TOKEN through. Verify the env nuance: env set on a uses: step isn't always visible to a composite action's inner steps — decide between requiring job/workflow-level env vs. a masked token input exported internally.
• branding: (icon/color) for the Marketplace.
• Maintain a moving v1 tag alongside goreleaser's release tags.
• README section with a usage example.
• (Optional) Publish to the GitHub Marketplace from a release.
• Example consumer workflow under examples/ or the README.

Follow-up to the CI/goreleaser work already in place.

Start with the existing Go CLI and CI/goreleaser setup, then inspect the release asset naming for the supported OS and architecture combinations. Add the root action.yml, README usage example, and optional examples/ workflow while resolving version selection, asset verification, and CONFLUENCE_TOKEN handling. Done means the composite action downloads and runs the requested release on Linux and macOS with the documented inputs.