MokoConsulting/MokoGIT
1
0
Fork 0
Code Issues 146 Pull Requests Releases 96 Wiki Activity

chore(deploy): rebuild + redeploy for moko-platform→mokocli manifest-schema rename (runner/mount preservation) #752

New Issue
Closed
opened 2026-07-05 23:42:45 +00:00 by jmiller · 5 comments
jmiller commented 2026-07-05 23:42:45 +00:00
Owner
Copy Link
Copy Source

Tracking issue for the forge-rebrand gate of the org-wide moko-platform/mokoplatform → mokocli normalization. The docs/wiki/workflow-path layers are already done org-wide; this issue covers the parts that require building a new MokoGitea image and redeploying (to be done in a dedicated deploy session).

1. Manifest schema + Go parser rebuild

The forge parses the repo manifest with a pinned element name:

  • services/repository/manifest_sync.go:17 → XMLName xml.Name \xml:"mokoplatform"``
  • models/repo/repo_manifest.go → comments ("mokoplatform metadata", "mokoplatform CLI") + standards_version field comment.

Repos ship .mokogitea/manifest.xml / .mokogitea/.moko-platform with root <moko-platform xmlns="https://standards.mokoconsulting.tech/moko-platform/1.0"> (and <mokoplatform> in the marker file). Renaming the element is a breaking schema change — parser and all manifests must flip together.

Recommended approach (backward-compatible): make the parser accept both mokoplatform and mokocli root elements (custom UnmarshalXML or a tolerant wrapper) rather than a hard swap, so existing manifests keep parsing during the migration and there's no hard cutover window. Decide whether to also emit mokocli on write or keep emitting the legacy name.

Tasks

  • Update manifest_sync.go parser to accept mokocli (ideally + legacy mokoplatform).
  • Update repo_manifest.go comments/labels; migrations/locale strings referencing "mokoplatform"/"MokoPlatform".
  • Build a new mokogitea image from this commit (CI → git.mokoconsulting.tech/mokoconsulting/mokogitea:<tag>).
  • Bump the image tag in /opt/mokogitea/docker-compose.yml and docker compose up -d (recreate gitea only).
  • Verify manifest API reads succeed for a sample repo post-deploy.
  • Migrate all repos' .mokogitea/manifest.xml + .moko-platform (<moko-platform>/<mokoplatform> + xmlns → mokocli) — atomic with / after the parser is live.

2. Workflow clone-URL cutover (deferred, needs verification)

Shared/platform workflows clone the CLI from .git URLs that were intentionally left as moko-platform.git during the docs pass because the external-mirror naming is unverified:

  • github.com/MokoConsulting/moko-platform.git (mirror backup) — confirm whether the GitHub mirror was renamed to mokocli.
  • ${MOKO_CLONE_HOST}/moko-platform.git — confirm the host/repo it resolves to.

Tasks

  • Verify GitHub mirror + MOKO_CLONE_HOST repo naming.
  • Then rename moko-platform.git → mokocli.git in the shared workflows at Template-Generic (auto-syncs). (Note: /opt/moko-platform → /opt/mokocli and INGROUP/REPO header tags are already normalized at the Template-Generic source; /opt/moko-platform remains a symlink to /opt/mokocli so old copies keep working.)

3. Runner + mount preservation (during the redeploy)

Recreating the gitea container must not disturb the CI runners or their live mounts. Checklist for the deploy:

  • 4 rootless-DinD act_runner containers (moko-act-runner, -02, -03, -release → gitea runners moko-beelink-01/02/03/release) stay registered and return healthy after recreate.
  • Live registration mounts at /opt/mokogitea-private/docker/act-runner/data-* are not deleted/re-created.
  • docker_host: "-" preserved in act_runner config (non-negotiable).
  • Host kernel.apparmor_restrict_unprivileged_userns=0 preserved.
  • network_mode: host (rootless image) unchanged.

4. Backup + rollback (before touching the running forge)

  • Fresh backup incl. MySQL keyring (/var/lib/mysql-keyring/) + gitea data + app.ini.
  • Record the current image tag (stable-122-gafe46361c7) for instant rollback (docker compose with the prior tag).
  • Never rm -rf /var/lib/gitea/.

Context

Part of the 2026-07 brand normalization (Gitea→MokoGitea, moko-platform→mokocli, MokoWaaS→MokoSuite, MokoStandards→org wiki). Everything except this gate and the live client-waas-*→client-mokosuite-* repo renames is already landed. /opt/moko-platform & /opt/mokoplatform are symlinks to /opt/mokocli; .mokogitea/.mokogitea-private are the canonical org wikis.

Tracking issue for the **forge-rebrand gate** of the org-wide `moko-platform`/`mokoplatform` → `mokocli` normalization. The docs/wiki/workflow-path layers are already done org-wide; this issue covers the parts that require **building a new MokoGitea image and redeploying** (to be done in a dedicated deploy session). ## 1. Manifest schema + Go parser rebuild The forge parses the repo manifest with a pinned element name: - `services/repository/manifest_sync.go:17` → `XMLName xml.Name \`xml:"mokoplatform"\`` - `models/repo/repo_manifest.go` → comments ("mokoplatform metadata", "mokoplatform CLI") + `standards_version` field comment. Repos ship `.mokogitea/manifest.xml` / `.mokogitea/.moko-platform` with root `<moko-platform xmlns="https://standards.mokoconsulting.tech/moko-platform/1.0">` (and `<mokoplatform>` in the marker file). Renaming the element is a **breaking schema change** — parser and all manifests must flip together. **Recommended approach (backward-compatible):** make the parser accept **both** `mokoplatform` and `mokocli` root elements (custom `UnmarshalXML` or a tolerant wrapper) rather than a hard swap, so existing manifests keep parsing during the migration and there's no hard cutover window. Decide whether to also emit `mokocli` on write or keep emitting the legacy name. **Tasks** - [ ] Update `manifest_sync.go` parser to accept `mokocli` (ideally + legacy `mokoplatform`). - [ ] Update `repo_manifest.go` comments/labels; migrations/locale strings referencing "mokoplatform"/"MokoPlatform". - [ ] Build a new `mokogitea` image from this commit (CI → `git.mokoconsulting.tech/mokoconsulting/mokogitea:<tag>`). - [ ] Bump the image tag in `/opt/mokogitea/docker-compose.yml` and `docker compose up -d` (recreate gitea only). - [ ] Verify manifest API reads succeed for a sample repo post-deploy. - [ ] Migrate all repos' `.mokogitea/manifest.xml` + `.moko-platform` (`<moko-platform>`/`<mokoplatform>` + xmlns → mokocli) — atomic with / after the parser is live. ## 2. Workflow clone-URL cutover (deferred, needs verification) Shared/platform workflows clone the CLI from `.git` URLs that were **intentionally left as `moko-platform.git`** during the docs pass because the external-mirror naming is unverified: - `github.com/MokoConsulting/moko-platform.git` (mirror backup) — confirm whether the GitHub mirror was renamed to `mokocli`. - `${MOKO_CLONE_HOST}/moko-platform.git` — confirm the host/repo it resolves to. **Tasks** - [ ] Verify GitHub mirror + `MOKO_CLONE_HOST` repo naming. - [ ] Then rename `moko-platform.git` → `mokocli.git` in the shared workflows at Template-Generic (auto-syncs). (Note: `/opt/moko-platform` → `/opt/mokocli` and `INGROUP`/`REPO` header tags are already normalized at the Template-Generic source; `/opt/moko-platform` remains a symlink to `/opt/mokocli` so old copies keep working.) ## 3. Runner + mount preservation (during the redeploy) Recreating the gitea container must not disturb the CI runners or their live mounts. Checklist for the deploy: - [ ] 4 rootless-DinD `act_runner` containers (`moko-act-runner`, `-02`, `-03`, `-release` → gitea runners `moko-beelink-01/02/03/release`) stay registered and return healthy after recreate. - [ ] Live registration mounts at `/opt/mokogitea-private/docker/act-runner/data-*` are **not** deleted/re-created. - [ ] `docker_host: "-"` preserved in act_runner config (non-negotiable). - [ ] Host `kernel.apparmor_restrict_unprivileged_userns=0` preserved. - [ ] `network_mode: host` (rootless image) unchanged. ## 4. Backup + rollback (before touching the running forge) - [ ] Fresh backup incl. **MySQL keyring** (`/var/lib/mysql-keyring/`) + gitea data + `app.ini`. - [ ] Record the current image tag (`stable-122-gafe46361c7`) for instant rollback (`docker compose` with the prior tag). - [ ] Never `rm -rf /var/lib/gitea/`. ## Context Part of the 2026-07 brand normalization (Gitea→MokoGitea, moko-platform→mokocli, MokoWaaS→MokoSuite, MokoStandards→org wiki). Everything except this gate and the live `client-waas-*`→`client-mokosuite-*` repo renames is already landed. `/opt/moko-platform` & `/opt/mokoplatform` are symlinks to `/opt/mokocli`; `.mokogitea`/`.mokogitea-private` are the canonical org wikis.
jmiller commented 2026-07-05 23:42:49 +00:00
Author
Owner
Copy Link
Copy Source

Branch created: feature/752-chore-deploy-rebuild-redeploy-for-moko-p

git fetch origin
git checkout feature/752-chore-deploy-rebuild-redeploy-for-moko-p
Branch created: [`feature/752-chore-deploy-rebuild-redeploy-for-moko-p`](https://git.mokoconsulting.tech/MokoConsulting/MokoGitea-Fork/src/branch/feature/752-chore-deploy-rebuild-redeploy-for-moko-p) ```bash git fetch origin git checkout feature/752-chore-deploy-rebuild-redeploy-for-moko-p ```
jmiller commented 2026-07-06 00:35:10 +00:00
Author
Owner
Copy Link
Copy Source

Bug found: bare /<owner>/<repo>/updates.xml serves an INCORRECT generated feed

While wiring the renamed ClarksvilleFurs client to auto-update, found that the bare repo-root update feed and the repo file disagree:

  • …/ClarksvilleFurs/client-mokosuite-clarksvillefurs/raw/branch/main/updates.xml → correct: <element>file_mokoonyx_clarksvillefurs</element>, <type>file</type> (matches the repo file on every branch).
  • …/ClarksvilleFurs/client-mokosuite-clarksvillefurs/updates.xml (bare path — this is what Joomla templateDetails.xml <updateservers> uses) → HTTP 200 but a generated feed emitting <name>Template - client-clarksvillefurs</name>, <element>tpl_clarksvillefurs</element>, <type>template</type>.

So the fork appears to generate a dynamic feed at the bare /updates.xml route, and for this repo it derives the wrong element/type (a tpl_ template rather than the actual file extension file_mokoonyx_clarksvillefurs). Joomla matches updates by (type, element), so the installed file/file_mokoonyx_clarksvillefurs extension never matches the generated template/tpl_clarksvillefurs feed → no client site auto-updates, silently.

Impact: likely affects all client sites whose templateDetails.xml points at the bare /updates.xml form (the standard client packaging). Worth auditing the fork's update-feed generation route (how it derives element/type/name — probably mis-mapping the .mokogitea/manifest.xml platform=client / package-type to a template).

Interim client-side fix applied to ClarksvilleFurs live DB: repointed the update site to the /raw/branch/main/updates.xml feed and corrected the installed extension element to file_mokoonyx_clarksvillefurs. The durable fix is here (correct the generated feed) so the bare-path form works as intended.

## Bug found: bare `/<owner>/<repo>/updates.xml` serves an INCORRECT generated feed While wiring the renamed ClarksvilleFurs client to auto-update, found that the **bare** repo-root update feed and the repo file disagree: - `…/ClarksvilleFurs/client-mokosuite-clarksvillefurs/raw/branch/main/updates.xml` → correct: `<element>file_mokoonyx_clarksvillefurs</element>`, `<type>file</type>` (matches the repo file on every branch). - `…/ClarksvilleFurs/client-mokosuite-clarksvillefurs/updates.xml` (bare path — **this is what Joomla `templateDetails.xml` `<updateservers>` uses**) → HTTP 200 but a **generated feed** emitting `<name>Template - client-clarksvillefurs</name>`, `<element>tpl_clarksvillefurs</element>`, `<type>template</type>`. So the fork appears to **generate** a dynamic feed at the bare `/updates.xml` route, and for this repo it derives the wrong element/type (a `tpl_` template rather than the actual `file` extension `file_mokoonyx_clarksvillefurs`). Joomla matches updates by (type, element), so the installed `file`/`file_mokoonyx_clarksvillefurs` extension never matches the generated `template`/`tpl_clarksvillefurs` feed → **no client site auto-updates**, silently. Impact: likely affects **all client sites** whose `templateDetails.xml` points at the bare `/updates.xml` form (the standard client packaging). Worth auditing the fork's update-feed generation route (how it derives `element`/`type`/`name` — probably mis-mapping the `.mokogitea/manifest.xml` `platform=client` / package-type to a template). Interim client-side fix applied to ClarksvilleFurs live DB: repointed the update site to the `/raw/branch/main/updates.xml` feed and corrected the installed extension element to `file_mokoonyx_clarksvillefurs`. The durable fix is here (correct the generated feed) so the bare-path form works as intended.
jmiller commented 2026-07-06 00:43:14 +00:00
Author
Owner
Copy Link
Copy Source

Correction to the above — not a fork code bug. The bare /updates.xml feed is generated correctly from the repo's first-class manifest metadata. Clarksville's metadata was simply stale: element_name=tpl_clarksvillefurs, extension_type=template (leftover from an earlier template-style setup). Corrected via PUT /repos/ClarksvilleFurs/client-mokosuite-clarksvillefurs/manifest → element_name=file_mokoonyx_clarksvillefurs, extension_type=file — and the bare feed immediately regenerated correctly (<type>file</type>, <element>file_mokoonyx_clarksvillefurs</element>, v01.12.00). Reverted the client update-site back to the canonical bare URL (dropped the /raw interim); installed extension element already corrected; site will auto-update 01.11.00 → 01.12.00.

Systemic follow-up: other client/extension repos may carry the same stale element_name/extension_type metadata (silent no-update). Recommend auditing each repo's manifest metadata against its actual Joomla extension <type>/<element>. (.mokogitea/manifest.xml is deprecated — the first-class fields are authoritative.) MCP tooling gap to set these fields directly tracked in mcp-mokogitea-api#33.

**Correction to the above — not a fork code bug.** The bare `/updates.xml` feed is generated correctly *from the repo's first-class manifest metadata*. Clarksville's metadata was simply **stale**: `element_name=tpl_clarksvillefurs`, `extension_type=template` (leftover from an earlier template-style setup). Corrected via `PUT /repos/ClarksvilleFurs/client-mokosuite-clarksvillefurs/manifest` → `element_name=file_mokoonyx_clarksvillefurs`, `extension_type=file` — and the bare feed **immediately regenerated correctly** (`<type>file</type>`, `<element>file_mokoonyx_clarksvillefurs</element>`, v01.12.00). Reverted the client update-site back to the canonical bare URL (dropped the `/raw` interim); installed extension element already corrected; site will auto-update 01.11.00 → 01.12.00. **Systemic follow-up:** other client/extension repos may carry the same stale `element_name`/`extension_type` metadata (silent no-update). Recommend auditing each repo's manifest metadata against its actual Joomla extension `<type>`/`<element>`. (`.mokogitea/manifest.xml` is deprecated — the first-class fields are authoritative.) MCP tooling gap to set these fields directly tracked in mcp-mokogitea-api#33.
jmiller commented 2026-07-06 02:44:49 +00:00
Author
Owner
Copy Link
Copy Source

Part 2 (workflow clone-URL cutover) — verified DONE ✅

Checked both prerequisites this session:

GitHub mirror naming: mokoconsulting-tech/MokoCLI exists (not archived); the old moko-platform / mokoplatform names resolve to it via GitHub's rename redirect. So the mirror rename → MokoCLI is complete.

Workflow clone URLs: grep of the fork's synced .mokogitea/workflows/ finds zero moko-platform.git references — every CLI clone already uses MokoCLI.git:

  • auto-bump.yml → git.mokoconsulting.tech/MokoConsulting/MokoCLI.git
  • auto-release.yml / pre-release.yml → ${MOKO_CLONE_HOST}/MokoCLI.git (MOKO_CLONE_HOST=git.mokoconsulting.tech/MokoConsulting, a workflow-level env, not an org var)
  • ci-issue-reporter.yml, workflow-sync-trigger.yml → .../MokoConsulting/MokoCLI.git

This matches the earlier Template-Generic MokoCLI.git fix (which syncs these workflows). No cutover work remains for Part 2. Any residual github.com/.../moko-platform.git in an external backup workflow still resolves via the redirect, but the canonical name is now MokoCLI.

Status of #752 gate

  • Part 1 (manifest.xml parser + /manifest alias removal, mokoplatform→mokocli) — ✅ merged to dev (PR #754)
  • Part 2 (workflow clone-URL cutover) — ✅ verified already complete (this comment)
  • Part 3/4 (production forge rebuild + redeploy with backup/keyring + runner-mount preservation + rollback tag stable-122-gafe46361c7) — ⏸️ remains; to be run in the deliberate dev → rc → main release (the code now rides with #733)

Related MCP work: tool rename gitea_*→mokogitea_* + metadata brand fix in mcp-mokogitea-api#33 (in progress).

## Part 2 (workflow clone-URL cutover) — verified DONE ✅ Checked both prerequisites this session: **GitHub mirror naming:** `mokoconsulting-tech/MokoCLI` exists (not archived); the old `moko-platform` / `mokoplatform` names resolve to it via GitHub's rename redirect. So the mirror rename → `MokoCLI` is complete. **Workflow clone URLs:** grep of the fork's synced `.mokogitea/workflows/` finds **zero `moko-platform.git` references** — every CLI clone already uses `MokoCLI.git`: - `auto-bump.yml` → `git.mokoconsulting.tech/MokoConsulting/MokoCLI.git` - `auto-release.yml` / `pre-release.yml` → `${MOKO_CLONE_HOST}/MokoCLI.git` (`MOKO_CLONE_HOST=git.mokoconsulting.tech/MokoConsulting`, a workflow-level env, not an org var) - `ci-issue-reporter.yml`, `workflow-sync-trigger.yml` → `.../MokoConsulting/MokoCLI.git` This matches the earlier Template-Generic `MokoCLI.git` fix (which syncs these workflows). No cutover work remains for Part 2. Any residual `github.com/.../moko-platform.git` in an external backup workflow still resolves via the redirect, but the canonical name is now `MokoCLI`. ## Status of #752 gate - **Part 1** (manifest.xml parser + `/manifest` alias removal, `mokoplatform`→`mokocli`) — ✅ merged to `dev` (PR #754) - **Part 2** (workflow clone-URL cutover) — ✅ verified already complete (this comment) - **Part 3/4** (production forge rebuild + redeploy with backup/keyring + runner-mount preservation + rollback tag `stable-122-gafe46361c7`) — ⏸️ remains; to be run in the deliberate `dev → rc → main` release (the code now rides with #733) Related MCP work: tool rename `gitea_*`→`mokogitea_*` + metadata brand fix in mcp-mokogitea-api#33 (in progress).
jmiller commented 2026-07-06 16:48:56 +00:00
Author
Owner
Copy Link
Copy Source

✅ Complete — closing

All parts of the forge-rebrand gate are done and live in production (verified 2026-07-06).

Part 1 — manifest schema + rebuild/redeploy: Rather than teach the XML parser the mokocli name, the deprecated .mokogitea/manifest.xml parser was removed (PR #754) along with the /manifest API alias; mokoplatform→mokocli. Shipped to prod via the #733 release — prod is now stable-289-gbc3bb0f778 (migration 368). Verified live: /metadata → 200, /manifest → 404.

Part 2 — workflow clone-URL cutover: Verified already done — workflows use MokoCLI.git, GitHub mirror is MokoCLI (see earlier comment).

Part 3 — runner + mount preservation: The prod redeploy preserved all 4 act_runner containers and their live mounts; runners healthy throughout.

Part 4 — backup + rollback: Fresh backup taken pre-release (/opt/gitea-dev/db-backups/pre-733-20260706-035650/ — DB + MySQL keyring + app.ini + rollback tag stable-122-gafe46361c7).

Deploy-workflow hardening (bonus): the auto-deploy (deploy-mokogitea.yml) failed on a container-name conflict + would have clobbered dev/rc compose tags via a blanket sed; completed manually and fixed the workflow (PR #758) + restored the compose.

Tracked separately: platform auto-detects nodejs not go (#753); client-repo metadata audit (comment above); MCP gitea_*→mokogitea_* rename (mcp-mokogitea-api #34, merged).

https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

## ✅ Complete — closing All parts of the forge-rebrand gate are done and **live in production** (verified 2026-07-06). **Part 1 — manifest schema + rebuild/redeploy:** Rather than teach the XML parser the `mokocli` name, the deprecated `.mokogitea/manifest.xml` parser was **removed** (PR #754) along with the `/manifest` API alias; `mokoplatform`→`mokocli`. Shipped to prod via the #733 release — prod is now `stable-289-gbc3bb0f778` (migration 368). Verified live: `/metadata` → 200, `/manifest` → 404. **Part 2 — workflow clone-URL cutover:** Verified already done — workflows use `MokoCLI.git`, GitHub mirror is `MokoCLI` (see earlier comment). **Part 3 — runner + mount preservation:** The prod redeploy preserved all 4 `act_runner` containers and their live mounts; runners healthy throughout. **Part 4 — backup + rollback:** Fresh backup taken pre-release (`/opt/gitea-dev/db-backups/pre-733-20260706-035650/` — DB + MySQL keyring + app.ini + rollback tag `stable-122-gafe46361c7`). **Deploy-workflow hardening (bonus):** the auto-deploy (`deploy-mokogitea.yml`) failed on a container-name conflict + would have clobbered dev/rc compose tags via a blanket `sed`; completed manually and **fixed the workflow** (PR #758) + restored the compose. Tracked separately: platform auto-detects `nodejs` not `go` (#753); client-repo metadata audit (comment above); MCP `gitea_*`→`mokogitea_*` rename (mcp-mokogitea-api #34, merged). https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 feature: wiki
Wiki system enhancements
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 mokostandards
Related to MokoStandards framework
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels
Priority Medium
Type Feature
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGIT#752
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?