From dea415044dbe08e4f5b6aacdb041dde1cb6a3b34 Mon Sep 17 00:00:00 2001 From: Neil Borromeo Date: Sun, 19 Apr 2026 13:53:06 +0800 Subject: [PATCH] Document reusable workflow URL requirement --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 8e129bf..44ffdf4 100644 --- a/README.md +++ b/README.md @@ -57,7 +57,7 @@ Site repos call the shared workflow with: jobs: deploy: runs-on: docker-desktop - uses: cliper/hugo_deployment/.forgejo/workflows/deploy-hugo-site.yml@v1 + uses: https://git.develton.com/cliper/hugo_deployment/.forgejo/workflows/deploy-hugo-site.yml@v1 with: deploy_script: ./scripts/deploy.sh secrets: @@ -68,6 +68,7 @@ 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..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