Run Hugo deployments on host runner

.forgejo/workflows/deploy-hugo-site.yml

@@ -33,13 +33,12 @@ jobs:
   deploy:
     name: ${{ inputs.workflow_name }}
     timeout-minutes: 20
-    runs-on: docker-desktop
+    runs-on: develton-hugo
-    container:
-      image: registry.develton.com/cliper/hugo-deployment:v1
     defaults:
       run:
         shell: bash
     env:
+      PATH: /snap/hugo/current/bin:/usr/local/bin:/usr/bin:/bin:/snap/bin
       DEPLOY_SSH_HOST: ${{ inputs.deploy_ssh_host != '' && inputs.deploy_ssh_host || vars.DEPLOY_SSH_HOST }}
       DEPLOY_SSH_PORT: ${{ vars.DEPLOY_SSH_PORT }}
       DEPLOY_SSH_USER: ${{ inputs.deploy_ssh_user != '' && inputs.deploy_ssh_user || vars.DEPLOY_SSH_USER }}

README.md

@@ -1,19 +1,18 @@
 # Hugo Deployment
 
-Shared Forgejo deployment image scaffold for Develton-managed Hugo sites.
+Shared Forgejo deployment workflow for Develton-managed Hugo sites.
 
 ## Contents
 
-- Prebuilt deployment image with Hugo, rsync, and OpenSSH client tools
+- Reusable Forgejo workflow for Hugo static-site deploys
-- Forgejo workflow that publishes versioned and `latest` image tags
+- Host-mode execution through the `develton-hugo` runner label
-- Image publish path intended for `registry.develton.com`
+- Legacy image publishing workflow retained for rollback/reference
 
 ## Prerequisites
 
 - Repository must be public if other repos call the reusable workflow directly
-- Forgejo variables: `REGISTRY_HOST`, `REGISTRY_USERNAME`
+- Caller repository variables and secrets documented below
-- Forgejo secrets: `REGISTRY_PASSWORD`
+- The runner host must provide `hugo`, `node`, `rsync`, and `ssh` on `PATH`
-- The image was smoke-tested locally, and `hugo version`, `rsync --version`, and `ssh -V` were confirmed successfully.
 
 ## Sites
 
@@ -26,7 +25,7 @@ Shared Forgejo deployment image scaffold for Develton-managed Hugo sites.
 
 ## Image Publishing
 
-The publish workflow runs on `docker-desktop` and publishes the versioned tag on every run.
+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`
@@ -56,7 +55,7 @@ Site repos call the shared workflow with:
 ```yaml
 jobs:
   deploy:
-    runs-on: docker-desktop
+    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
@@ -69,10 +68,8 @@ 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 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 always runs on `docker-desktop`
+- The reusable workflow itself runs on `develton-hugo`.
-- 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
+- The reusable workflow intentionally does not set `jobs.<job_id>.container`.
-- 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`