- Python 88.5%
- Dockerfile 11.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
Publish Hugo Deployment Image / publish (push) Successful in 54s
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. |
||
| .forgejo/workflows | ||
| tests | ||
| .dockerignore | ||
| Dockerfile | ||
| README.md | ||
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-hugorunner 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, andsshonPATH; the workflow downloads Hugo itself
Sites
neilborromeo.comboholtoday.comboholcentral.comkomsysnet.comthefreelancemastery.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
mainpublishregistry.develton.com/cliper/hugo-deployment:<commit-sha>and also movelatest - Pushes of Git tags like
v1publish the matching image tag without movinglatest - Manual runs can override the tag with
image_tag - Manual runs do not move
latestunlesspublish_latestis set totrue
It pushes:
registry.develton.com/cliper/hugo-deployment:<tag>registry.develton.com/cliper/hugo-deployment:latest
Required variables and secrets:
REGISTRY_HOSTREGISTRY_USERNAMEREGISTRY_PASSWORD
Workflow inputs:
image_tagpublish_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, andDEPLOY_PATHare required repo variables unless the caller explicitly passes host and user as workflow inputs - Caller repos pass
DEPLOY_SSH_KEYthroughjobs.<job_id>.secrets; Forgejo v11 accepts caller-provided reusable workflow secrets even thoughon.workflow_callitself only documentsinputsandoutputs - Caller workflows should use the fully qualified workflow URL because shorthand cross-repo
owner/repo/...@refresolution on the current Develton Forgejo instance is producinghttps:///...clone URLs for reusable workflows - Caller workflows should keep
runs-on: develton-hugoon the job that uses this reusable workflow. - Caller repos can set
DEPLOY_KNOWN_HOSTSin repo variables with a pinnedknown_hostsentry for stronger host verification - If
DEPLOY_KNOWN_HOSTSis not set, the workflow falls back tossh-keyscanso current repos keep working - The reusable workflow itself runs on
develton-hugo. - The reusable workflow intentionally does not set
jobs.<job_id>.container.