Hugo reusable deployment workflow
  • Python 88.5%
  • Dockerfile 11.5%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Neil Borromeo 366b448bb0
All checks were successful
Publish Hugo Deployment Image / publish (push) Successful in 54s
Pin checksummed Hugo download in shared workflow
The deploy job downloads Hugo Extended 0.165.0 from the GitHub release,
verifies its SHA-256 and runs it from RUNNER_TEMP instead of the runner's
auto-refreshing snap. Deploys fail before rsync if hugo is a different
version, not Extended, or not the pinned binary.
2026-10-19 15:48:34 +08:00
.forgejo/workflows Pin checksummed Hugo download in shared workflow 2026-10-19 15:48:34 +08:00
tests Pin checksummed Hugo download in shared workflow 2026-10-19 15:48:34 +08:00
.dockerignore Add shared Hugo deployment workflows 2026-04-19 11:51:51 +08:00
Dockerfile Pin checksummed Hugo download in shared workflow 2026-10-19 15:48:34 +08:00
README.md Pin checksummed Hugo download in shared workflow 2026-10-19 15:48:34 +08:00

Hugo Deployment

Shared Forgejo deployment workflow for Develton-managed Hugo sites.

Contents

  • Reusable Forgejo workflow for Hugo static-site deploys
  • Host-mode execution through the develton-hugo runner label
  • Legacy image publishing workflow retained for rollback/reference

Prerequisites

  • Repository must be public if other repos call the reusable workflow directly
  • Caller repository variables and secrets documented below
  • The runner host must provide curl, tar, sha256sum, rsync, and ssh on PATH; the workflow downloads Hugo itself

Sites

  • neilborromeo.com
  • boholtoday.com
  • boholcentral.com
  • komsysnet.com
  • thefreelancemastery.com

All five sites deploy through the shared workflow, which downloads Hugo Extended 0.165.0 from the GitHub release, verifies its pinned SHA-256, and runs it from $RUNNER_TEMP. A checksum mismatch, a different version, a non-Extended build, or any other hugo first on PATH fails before deployment.

To change the version, update HUGO_VERSION and HUGO_SHA256 together (hash from hugo_<version>_checksums.txt), plus the Dockerfile ARG and the tests.

Image Publishing

The legacy publish workflow can still publish the old container image, but normal deployments no longer use it. The legacy image is also pinned to Hugo Extended 0.165.0. Hugo deploys run directly on the runner host so they can use the pinned Hugo download and avoid nested container deployment paths.

  • Pushes to main publish registry.develton.com/cliper/hugo-deployment:<commit-sha> and also move latest
  • Pushes of Git tags like v1 publish the matching image tag without moving latest
  • Manual runs can override the tag with image_tag
  • Manual runs do not move latest unless publish_latest is set to true

It pushes:

  • registry.develton.com/cliper/hugo-deployment:<tag>
  • registry.develton.com/cliper/hugo-deployment:latest

Required variables and secrets:

  • REGISTRY_HOST
  • REGISTRY_USERNAME
  • REGISTRY_PASSWORD

Workflow inputs:

  • image_tag
  • publish_latest

Reusable Workflow

Site repos call the shared workflow with:

jobs:
  deploy:
    runs-on: develton-hugo
    uses: https://git.develton.com/cliper/hugo_deployment/.forgejo/workflows/deploy-hugo-site.yml@main
    with:
      deploy_script: ./scripts/deploy.sh
    secrets:
      deploy_ssh_key: ${{ secrets.DEPLOY_SSH_KEY }}

Notes:

  • For the current caller pattern, DEPLOY_SSH_HOST, DEPLOY_SSH_USER, and DEPLOY_PATH are required repo variables unless the caller explicitly passes host and user as workflow inputs
  • Caller repos pass DEPLOY_SSH_KEY through jobs.<job_id>.secrets; Forgejo v11 accepts caller-provided reusable workflow secrets even though on.workflow_call itself only documents inputs and outputs
  • Caller workflows should use the fully qualified workflow URL because shorthand cross-repo owner/repo/...@ref resolution on the current Develton Forgejo instance is producing https:///... clone URLs for reusable workflows
  • Caller workflows should keep runs-on: develton-hugo on the job that uses this reusable workflow.
  • Caller repos can set DEPLOY_KNOWN_HOSTS in repo variables with a pinned known_hosts entry for stronger host verification
  • If DEPLOY_KNOWN_HOSTS is not set, the workflow falls back to ssh-keyscan so current repos keep working
  • The reusable workflow itself runs on develton-hugo.
  • The reusable workflow intentionally does not set jobs.<job_id>.container.