docs-update and docs-locale-sync workflows are skipped on every run #57623

Activity

1. opencode-agent commented on Oct 21, 2026

   

   opencode-agentBot

   on Oct 21, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I can confirm it on the latest dev (c9b5a9f).

   • docs-update.yml still gates its job on if: github.repository == 'sst/opencode' and still calls the action as sst/opencode/github@…. The public Actions API shows 27 successful runs, the last on 2026-01-02, and every run since then (582) skipped, the latest today. So it did work until about the org transfer and has been dead since, because the repository check was never updated.
   • docs-locale-sync.yml has if: false. The API shows 11 successes up to 2026-03-09 and then 34 failures up to 2026-03-29, after which every run is skipped. It looks like it was switched off on purpose after those failures, but there's no comment saying so. Whether to re-enable it or document why it's off is up to the maintainers.

   One correction to the steps: older successful runs do exist, but nothing has actually run since January (docs-update) or March (locale sync).

   The script below prints the job conditions and the run counts by status; it needs no token.

   Earlier reports of the same docs-update problem, which closed without a merged fix:

   • docs-update GitHub Action Workflow is skipped due to old repo reference #16045: same skipped docs-update runs after the transfer (closed as stale)
   • docs-update.yml references sst/opencode instead of anomalyco/opencode #31471: same, including the sst/opencode/github action reference
   • [BUG] docs-update still references old repo; infra DO migration tag is a no-op #24326: same, plus an unrelated infra point; fix PRs fix: update repo name in docs-update conditional #16044, fix(ci): update docs-update repo references after org transfer #16091 and fix: correct docs update workflow and infra tag #24330 were closed without being merged

   Reproduction script (check-docs-workflows.sh)

   #!/usr/bin/env bash
   # Shows that docs-update / docs-locale-sync never run their jobs in anomalyco/opencode.
   # Usage: bash check-docs-workflows.sh [path-to-opencode-checkout-on-dev]
   set -euo pipefail
   REPO_DIR="${1:-.}"
   API="https://api.github.com/repos/anomalyco/opencode/actions/workflows"
   
   echo "== job gates on $(git -C "$REPO_DIR" rev-parse HEAD)"
   grep -n "if: github.repository\|uses: sst/" "$REPO_DIR/.github/workflows/docs-update.yml"
   grep -n "^    if:\|^    #if:" "$REPO_DIR/.github/workflows/docs-locale-sync.yml"
   
   for w in docs-update.yml docs-locale-sync.yml; do
     echo "== $w: run counts by status (and most recent run with that status)"
     for s in success failure skipped; do
       curl -s "$API/$w/runs?per_page=1&status=$s" | python3 -c '
   import json,sys
   d=json.load(sys.stdin); r=d.get("workflow_runs",[])
   print("  %-8s %s %s" % (sys.argv[1], d.get("total_count"), r[0]["created_at"] if r else "-"))' "$s"
     done
   done

   Run it: bash check-docs-workflows.sh
2. opencode-agent

   added

   reproduced

   on Oct 21, 2026
3. Dante-dan commented on Oct 21, 2026

   

   Dante-dan

   on Oct 21, 2026

   Contributor

   More actions

   There are two additional preflight checks before changing the repository guard:

   • The exact action pin, 2c14fc5586fe0b88e5c04732d2e846769cc35671, is currently unavailable at the canonical raw action URL (404), and the commits API returns 422 / “No commit found for SHA”. This does not prove what happened in historical Actions runs. The old sst/opencode REST endpoint redirects successfully to anomalyco/opencode, so the old owner name alone does not establish that the action reference is broken.
   • At dev 15adc3d, the checked agent directory contains duplicate-pr.md and triage.md, but no docs.md or translator.md. The current action's agent input documents fallback to default_agent / build when the requested agent is absent. These are current-source checks, not evidence about the unavailable action revision; the effective agent configuration needs validation before restoring automation.

   I suggest keeping locale sync disabled and treating docs-update restoration as a separate, bounded change: select a resolvable action revision, verify the intended docs agent/configuration, then update the repository guard if this repository is meant to host the bot. Changing that guard activates a job with contents/PR/id-token write permissions and OPENCODE_API_KEY, so it needs an explicit deployment decision rather than just a string replacement. Please confirm whether docs-update should run here; locale sync can remain outside that scope. I have not run or enabled either workflow.
4. oke3 commented on Oct 21, 2026

   

   oke3

   on Oct 21, 2026

   ContributorAuthor

   More actions

   Two pieces of evidence for the preflight, from a checkout of dev at 5c52626:

   • A resolvable action revision exists. The pinned 2c14fc55… is gone (raw URL 404, commits API "No commit found for SHA"), but github/action.yml is still in the repo and was last touched by 5c5262660f87d3327868af3559a71810fefe2bed (2026-10-20), which is the current dev HEAD. Pinning that SHA makes uses: sst/opencode/github@5c52626… resolvable through the sst/opencode → anomalyco/opencode redirect — the REST endpoint still answers 301 → repositories/975734319.

   • The agent fallback is the part that would change behaviour. github/action.yml documents its agent input as "Must be a primary agent. Falls back to default_agent from config or 'build' if not found", and .opencode/agent/ on dev contains only duplicate-pr.md and triage.md — so a docs/translator agent request falls back to build rather than the docs agent the workflow was written for.

   Not touching either workflow; flagging it since the guard change alone would activate a job with contents/PR/id-token write permissions and OPENCODE_API_KEY.
5. Kissshot-2003 commented on Oct 22, 2026

   

   Kissshot-2003

   on Oct 22, 2026

   More actions

   There is a second stale thing next to the if: gate, and it decides whether a fix is a one-liner or not.

   Both workflows point at packages/web/src/content/docs/. That is the v1 tree — its astro.config.mjs sets base: "/docs", so it is what opencode.ai/docs/ serves. The v2 tree is services/www/src/docs/content/, and its astro.config.ts sets base: "/v2/".

   So the two trees are not interchangeable, and the locale story differs between them:

   • the v1 tree has 17 locale directories (ar, bs, da, de, es, fr, it, ja, ko, nb, pl, pt-br, ru, th, tr, zh-cn, zh-tw)
   • the v2 tree has no locale directories at all — 24 pages and three subdirectories (build/, cli/, console/), no translations

   Which means the if: false on docs-locale-sync.yml is not the only reason the translations are frozen. Even with the gate fixed, that workflow would keep syncing the v1 copies, and the v2 pages would stay untranslated.

   How far the v1 translations have drifted

   Since the sync stopped, the Chinese copies fell behind the English ones. Comparing the heading lists of every page in the v1 tree:

   page	english headings	zh-cn headings
   providers.mdx	58	47
   config.mdx	39	32
   cli.mdx	29	25
   troubleshooting.mdx	23	22
   tools.mdx	19	18
   permissions.mdx	11	10
   keybinds.mdx	6	5
   policies.mdx	5	not translated
   references.mdx	6	not translated

   9 of the 33 English pages are behind, and 2 have no Chinese translation at all. The keybinds.mdx gap is a whole missing section: the English page has ## Binding Values, which explains that a binding value may be one shortcut, several comma-separated shortcuts, an array, or an object with key / event / preventDefault / fallthrough. The Chinese page never got it.

   What I can do without touching the workflow

   The frozen sync does not have to be fixed before a translation can land, so I went ahead and filled one of the gaps: #58017

   That one is a single missing section in zh-cn/keybinds.mdx, translated against the .opencode/glossary/zh-cn.md terms and the wording already used on the page.

   The question that decides the rest

   Which tree is canonical for this? If it is the v2 tree, then the fix is not a one-line gate change: docs-locale-sync.yml would need to point at services/www/src/docs/content/, and the locale infrastructure would have to be built for the v2 tree from scratch, since it has no locale directories yet. If it is the v1 tree, the gate is the whole fix and the two untranslated pages plus the 7 short pages are the backlog.

   Happy to do either. I can also just work through the 9 drifting pages in the v1 tree one PR per page, which needs no answer to the question above, and keep going while that is decided.
6. oke3 commented on Oct 22, 2026

   

   oke3

   on Oct 22, 2026

   ContributorAuthor

   More actions

   Good catch on the two trees — that is the part I missed, and it does change what the fix is.

   Two things I can add, both checked against the workflows in this repo:

   The two workflows are self-consistent, and they point at the tree that actually serves /docs. docs-update.yml checks and writes packages/web/src/content/docs/* (lines 62 and 64), and docs-locale-sync.yml watches, diffs and updates packages/web/src/content/docs/*.mdx and packages/web/src/content/docs/<locale>/ (lines 8, 38, 79, 86). That is the v1 tree — base: "/docs" — so un-freezing the gate re-enables the English update and the locale sync for the same tree. The v2 tree has no locale infrastructure at all, so "give v2 translations" is a separate project, not part of this gate.

   On which tree is canonical: the /docs page is already where the v2 content is landing. Three pieces of evidence from this repo alone:

   • docs-update.yml was told to check and update packages/web/src/content/docs/* — the v1 tree — when the CLI it documents is v2.
   • docs: correct plan agent permissions and use shell tool name #56922 and docs: describe agent creation without the removed CLI command #57419 (both yours/the team's) move that page to v2 behaviour: "describe agent creation without the removed CLI command", "remove references to deleted scout agent".
   • The review bot on my docs(cli): document the opencode debug subcommands #57861 said the page is "on dev, where the CLI is v2", and that PR is now merged — the v2 opencode debug subcommands landed on the /docs page.

   So the tree keeps the name and the location, and the content is migrating to v2. The locale backlog on that tree is therefore not wasted work — it is the backlog of the page users are actually reading.

   What I can take. The nine drifting pages are one-PR-per-page work that needs no answer to the canonical question, exactly like #58017. The two with no Chinese copy at all — policies.mdx and references.mdx — are the most self-contained. I would rather not invent terminology, so I would work from .opencode/glossary/zh-cn.md and mirror the wording already used on the English page, and let a Chinese-reading reviewer correct it; if that is not good enough, say so and I will leave the translations to someone who writes Chinese natively and take a different slice instead.

   One caveat on my side: I have been wrong twice in this thread already (the v1 debug subcommands, and a coverage claim that a parameterised test already covered), so treat this offer as a proposal, not a finished thing.