dea415044d
All checks were successful
Publish Hugo Deployment Image / publish (push) Successful in 23s
78 lines
3.4 KiB
Markdown
78 lines
3.4 KiB
Markdown
# 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:
|
|
|
|
```yaml
|
|
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`
|