# 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 `hugo`, `node`, `rsync`, and `ssh` on `PATH`

## Sites

- `neilb.com`
- `boholtoday.com`
- `boholcentral.com`
- `cloud.develton.com`
- `komsysnet.com`
- `thefreelancemastery.com`

## Image Publishing

The legacy publish workflow can still publish the old container image, but normal deployments no longer use it. Hugo deploys run directly on the runner host so they can use the host Hugo binary 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:

```yaml
jobs:
  deploy:
    runs-on: develton-hugo
    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: 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`.