guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

Update Website fails #360

New Issue
Closed
opened 2026-06-03 11:38:20 +00:00 by guettli · 2 comments
guettli commented 2026-06-03 11:38:20 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Update website fails:

https://codeberg.org/guettli/sharedinbox/actions/runs/1394/jobs/0/attempt/1

Why, and how to fix?

Update website fails: https://codeberg.org/guettli/sharedinbox/actions/runs/1394/jobs/0/attempt/1 Why, and how to fix?
guettlibot commented 2026-06-03 11:50:02 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

I'll read the project conventions and CI configuration to understand the failing "Update Website" job.The main docs aren't local. Let me explore what's available locally and fetch the failing CI run.Let me look at the DAGGER.md and recent git commits for more context.I have enough context now. Let me synthesize the root cause.

The workflow file is clear. The Dockerfile installs dagger and task, but commit #354 ("migrate CI secrets from Forgejo to SOPS") added scripts/setup_dagger_remote.sh which calls sops to decrypt secrets.enc.yaml — and sops is not in the runner image.Now I have a clear picture. Here's my implementation plan:

Root Cause

Commit #354 ("migrate CI secrets from Forgejo to SOPS") introduced scripts/setup_dagger_remote.sh, which calls:

sops --decrypt --output-type json secrets.enc.yaml > "$SECRETS_JSON"

However, sops was never added to the act-runner Docker image. The .forgejo/Dockerfile only installs dagger (v0.20.8) and task (v3.48.0). When the Setup Dagger Remote Engine step runs, the shell finds no sops binary and exits with an error, aborting all remaining steps (deploy and verify).

secrets.enc.yaml was created with sops v3.13.1 (visible in the file's metadata).

Implementation Plan

Step 1 — Add sops to .forgejo/Dockerfile

Append a RUN layer after the existing installs, pinned to match the version used to encrypt the file:

# sops — must match (or be forward-compatible with) the version used to encrypt secrets.enc.yaml
RUN curl -fsSL \
      https://github.com/getsops/sops/releases/download/v3.13.1/sops-v3.13.1.linux.amd64 \
      -o /usr/local/bin/sops \
    && chmod +x /usr/local/bin/sops

Using the static binary avoids any package-manager friction on the Ubuntu base image.

Step 2 — Sync the Dockerfile to the runner host

The file comment says it is manually copied to the host:

# Install at on the act-runner host on: /etc/forgejo/runner/Dockerfile

Copy the updated file there and restart the service so ExecStartPre=docker build … rebuilds the image before the next run.

Step 3 — Verify

Re-trigger the "Update Website" workflow (via workflow_dispatch or a push touching website/**). All five steps should now succeed:

  • Check runner tools — command -v dagger and command -v task pass (sops is not checked here, but would be worth adding)
  • Setup Dagger Remote Engine — sops --decrypt succeeds, secrets exported, SSH tunnel established
  • Build & Update Website — Dagger pipeline runs
  • Verify Website — https://sharedinbox.de/ returns HTTP 200 with the expected x-version git hash

Optional follow-up

Add a sops presence check to the "Check runner tools" step so future omissions are caught early with a clear error message:

command -v sops >/dev/null 2>&1 || { echo "ERROR: sops is not installed in the runner image. Add it to .forgejo/Dockerfile."; exit 1; }
I'll read the project conventions and CI configuration to understand the failing "Update Website" job.The main docs aren't local. Let me explore what's available locally and fetch the failing CI run.Let me look at the DAGGER.md and recent git commits for more context.I have enough context now. Let me synthesize the root cause. The workflow file is clear. The Dockerfile installs `dagger` and `task`, but commit #354 ("migrate CI secrets from Forgejo to SOPS") added `scripts/setup_dagger_remote.sh` which calls `sops` to decrypt `secrets.enc.yaml` — and `sops` is not in the runner image.Now I have a clear picture. Here's my implementation plan: --- ## Root Cause Commit #354 ("migrate CI secrets from Forgejo to SOPS") introduced `scripts/setup_dagger_remote.sh`, which calls: ```bash sops --decrypt --output-type json secrets.enc.yaml > "$SECRETS_JSON" ``` However, `sops` was never added to the act-runner Docker image. The `.forgejo/Dockerfile` only installs `dagger` (v0.20.8) and `task` (v3.48.0). When the `Setup Dagger Remote Engine` step runs, the shell finds no `sops` binary and exits with an error, aborting all remaining steps (deploy and verify). `secrets.enc.yaml` was created with sops v3.13.1 (visible in the file's metadata). --- ## Implementation Plan ### Step 1 — Add `sops` to `.forgejo/Dockerfile` Append a `RUN` layer after the existing installs, pinned to match the version used to encrypt the file: ```dockerfile # sops — must match (or be forward-compatible with) the version used to encrypt secrets.enc.yaml RUN curl -fsSL \ https://github.com/getsops/sops/releases/download/v3.13.1/sops-v3.13.1.linux.amd64 \ -o /usr/local/bin/sops \ && chmod +x /usr/local/bin/sops ``` Using the static binary avoids any package-manager friction on the Ubuntu base image. ### Step 2 — Sync the Dockerfile to the runner host The file comment says it is manually copied to the host: ``` # Install at on the act-runner host on: /etc/forgejo/runner/Dockerfile ``` Copy the updated file there and restart the service so `ExecStartPre=docker build …` rebuilds the image before the next run. ### Step 3 — Verify Re-trigger the "Update Website" workflow (via `workflow_dispatch` or a push touching `website/**`). All five steps should now succeed: - `Check runner tools` — `command -v dagger` and `command -v task` pass (sops is not checked here, but would be worth adding) - `Setup Dagger Remote Engine` — `sops --decrypt` succeeds, secrets exported, SSH tunnel established - `Build & Update Website` — Dagger pipeline runs - `Verify Website` — `https://sharedinbox.de/` returns HTTP 200 with the expected `x-version` git hash ### Optional follow-up Add a `sops` presence check to the "Check runner tools" step so future omissions are caught early with a clear error message: ```bash command -v sops >/dev/null 2>&1 || { echo "ERROR: sops is not installed in the runner image. Add it to .forgejo/Dockerfile."; exit 1; } ```
guettlibot commented 2026-06-03 14:05:02 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Let me start by exploring the repository structure and understanding the failure.Now let me check the setup script and the CI Dagger module for the publish-website function.Now let me look at the GenerateBuildHistory function and the script it calls.Let me check the website verify script and look at recent CI changes.Let me also read the deploy.yml and ci.yml workflows to compare.Let me look at the Hugo function in main.go and check if HUGO_PARAMS_GITVERSION is set.Let me check how x-version and HUGO_PARAMS_GITVERSION are used in the website templates.Now I understand the issue. The BuildWebsite Dagger function doesn't set HUGO_PARAMS_GITVERSION, but website-verify.sh looks for the x-version meta tag which is only rendered when that env var is passed to Hugo. The verify step will always fail because the deployed site never contains the version string.

Let me look at the full ci/main.go to understand the structure before making changes.Now I have a clear picture. The fix is:

  1. Add an optional commitHash parameter to BuildWebsite and PublishWebsite in ci/main.go, and use it to set HUGO_PARAMS_GITVERSION in the Hugo build.
  2. Update task publish-website in Taskfile.yml to pass --commit-hash "$(git rev-parse --short HEAD)".Now update the Taskfile to pass the commit hash:Now let me verify the changes look correct:The changes look correct. Now let me also check whether there's a go vet or compilation check I should run on the ci module:The go vet error is a pre-existing go.sum mismatch unrelated to my changes. Let me verify the Go syntax of my changes is correct by checking the local go tools on just the function signatures:gofmt parses cleanly. Let me also read back the modified section to double-check:The changes look correct. Now let me commit this on a new branch and open a PR.The PR is open at https://codeberg.org/guettli/sharedinbox/pulls/362.

Root cause: BuildWebsite in ci/main.go ran hugo --minify without setting HUGO_PARAMS_GITVERSION. Hugo uses that env var to populate site.Params.gitversion, which the extend_head.html partial renders as <meta name="x-version" content="...">. Without that tag, website-verify.sh — which greps for x-version.*${VERSION} in the live HTML — always timed out and failed, even though the site itself was deployed correctly.

Fix:

  • Added an optional commitHash parameter to BuildWebsite and PublishWebsite in ci/main.go; when set, it is passed to the Hugo container via WithEnvVariable("HUGO_PARAMS_GITVERSION", commitHash).
  • Updated task publish-website in Taskfile.yml to compute HASH=$(git rev-parse --short HEAD) and pass --commit-hash "$HASH" to the Dagger call — exactly as task deploy-linux already does.
Let me start by exploring the repository structure and understanding the failure.Now let me check the setup script and the CI Dagger module for the `publish-website` function.Now let me look at the `GenerateBuildHistory` function and the script it calls.Let me check the website verify script and look at recent CI changes.Let me also read the deploy.yml and ci.yml workflows to compare.Let me look at the Hugo function in main.go and check if HUGO_PARAMS_GITVERSION is set.Let me check how `x-version` and `HUGO_PARAMS_GITVERSION` are used in the website templates.Now I understand the issue. The `BuildWebsite` Dagger function doesn't set `HUGO_PARAMS_GITVERSION`, but `website-verify.sh` looks for the `x-version` meta tag which is only rendered when that env var is passed to Hugo. The verify step will always fail because the deployed site never contains the version string. Let me look at the full `ci/main.go` to understand the structure before making changes.Now I have a clear picture. The fix is: 1. Add an optional `commitHash` parameter to `BuildWebsite` and `PublishWebsite` in `ci/main.go`, and use it to set `HUGO_PARAMS_GITVERSION` in the Hugo build. 2. Update `task publish-website` in `Taskfile.yml` to pass `--commit-hash "$(git rev-parse --short HEAD)"`.Now update the Taskfile to pass the commit hash:Now let me verify the changes look correct:The changes look correct. Now let me also check whether there's a `go vet` or compilation check I should run on the ci module:The `go vet` error is a pre-existing `go.sum` mismatch unrelated to my changes. Let me verify the Go syntax of my changes is correct by checking the local `go` tools on just the function signatures:`gofmt` parses cleanly. Let me also read back the modified section to double-check:The changes look correct. Now let me commit this on a new branch and open a PR.The PR is open at **https://codeberg.org/guettli/sharedinbox/pulls/362**. --- **Root cause:** `BuildWebsite` in `ci/main.go` ran `hugo --minify` without setting `HUGO_PARAMS_GITVERSION`. Hugo uses that env var to populate `site.Params.gitversion`, which the `extend_head.html` partial renders as `<meta name="x-version" content="...">`. Without that tag, `website-verify.sh` — which greps for `x-version.*${VERSION}` in the live HTML — always timed out and failed, even though the site itself was deployed correctly. **Fix:** - Added an optional `commitHash` parameter to `BuildWebsite` and `PublishWebsite` in `ci/main.go`; when set, it is passed to the Hugo container via `WithEnvVariable("HUGO_PARAMS_GITVERSION", commitHash)`. - Updated `task publish-website` in `Taskfile.yml` to compute `HASH=$(git rev-parse --short HEAD)` and pass `--commit-hash "$HASH"` to the Dagger call — exactly as `task deploy-linux` already does.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels loop/code-done
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#360