Hugo Deployment

Shared Forgejo deployment image scaffold for Develton-managed Hugo sites.

Contents

• Prebuilt deployment image with Hugo, rsync, and OpenSSH client tools
• Forgejo workflow that publishes versioned and latest image tags
• Image publish path intended for registry.develton.com

Prerequisites

• Repository must be public if other repos call the reusable workflow directly
• Forgejo variables: REGISTRY_HOST, REGISTRY_USERNAME
• Forgejo secrets: REGISTRY_PASSWORD
• The image was smoke-tested locally, and hugo version, rsync --version, and ssh -V were confirmed successfully.

Sites

• neilb.com
• boholtoday.com
• boholcentral.com
• cloud.develton.com
• komsysnet.com
• thefreelancemastery.com

Image Publishing

The publish workflow runs on docker-desktop and publishes the versioned tag on every run.

• 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: docker-desktop
    uses: https://git.develton.com/cliper/hugo_deployment/.forgejo/workflows/deploy-hugo-site.yml@v1
    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: docker-desktop on the job that uses this reusable workflow when running against the current Develton Forgejo instance, which avoids buggy workflow expansion on the server side
• 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 always runs on docker-desktop
• The reusable workflow resolves its container image as registry.develton.com/cliper/hugo-deployment:v1, so caller repos do not need REGISTRY_HOST just to start the job
• Because the reusable workflow job container is resolved before checkout, callers must not switch over until registry.develton.com/cliper/hugo-deployment:v1 has been published and verified pullable by the runner
• The reusable workflow is currently pinned to registry.develton.com/cliper/hugo-deployment:v1