MokoConsulting/MokoGitea-APP
1
0
Fork 0
Code Issues 158 Pull Requests 3 Releases 96 Wiki Activity

feat(settings): repo settings tab for manifest.xml / update stream metadata #315

New Issue
Closed
opened 2026-05-31 14:15:03 +00:00 by jmiller · 3 comments
jmiller commented 2026-05-31 14:15:03 +00:00
Owner
Copy Link
Copy Source

Summary

Add a new "Update Feed" tab in repo settings that exposes manifest.xml fields for configuring how the repository appears in update feeds (Joomla updates.xml, Dolibarr JSON).

Motivation

Currently, update feed metadata (display names, descriptions, platform type, version format) is either hardcoded or derived from repo metadata. Repos need a dedicated settings UI to configure:

  • Display name — how the extension appears in update feeds (e.g. "Moko CRM Module" vs the repo name)
  • Update description — short text shown to end-users in their CMS update manager
  • Platform type — joomla / dolibarr / both (already partially exists as RepoUpdatePlatform)
  • Version format — how tags map to version strings in the feed
  • Minimum platform version — e.g. "Joomla 4.0" or "Dolibarr 16.0"
  • Extension type — component, module, plugin, package (Joomla) or module (Dolibarr)
  • Folder/element — Joomla-specific manifest identifiers
  • Info URL — link shown in the update manager for more details
  • Icon URL — extension icon in update feeds

Schema Reference

Fields align with the moko-platform manifest schema at:

And the existing structure in repos.

Implementation Plan

  1. Model: Add table (or extend existing ) with the above fields
  2. Router: handler in
  3. Template: with form fields
  4. Navbar: Add tab to
  5. Integration: Update and to read these settings when generating feeds

UI Mockup

Settings > Update Feed tab with sections:

  • Identity: Display name, description, icon URL, info URL
  • Platform: Type selector (Joomla/Dolibarr/Both), minimum version, extension type
  • Joomla-specific (shown when platform includes Joomla): element, folder, client (site/admin)
  • Versioning: Version format pattern, channel mapping rules

Related

  • #239 (update server feature — this adds the settings UI for it)
  • #304 (permissions — uses TypeLicenses unit, this would need similar access control)

— Claude Opus 4.6 (1M context) noreply@anthropic.com

## Summary Add a new **"Update Feed"** tab in repo settings that exposes manifest.xml fields for configuring how the repository appears in update feeds (Joomla updates.xml, Dolibarr JSON). ## Motivation Currently, update feed metadata (display names, descriptions, platform type, version format) is either hardcoded or derived from repo metadata. Repos need a dedicated settings UI to configure: - **Display name** — how the extension appears in update feeds (e.g. "Moko CRM Module" vs the repo name) - **Update description** — short text shown to end-users in their CMS update manager - **Platform type** — joomla / dolibarr / both (already partially exists as RepoUpdatePlatform) - **Version format** — how tags map to version strings in the feed - **Minimum platform version** — e.g. "Joomla 4.0" or "Dolibarr 16.0" - **Extension type** — component, module, plugin, package (Joomla) or module (Dolibarr) - **Folder/element** — Joomla-specific manifest identifiers - **Info URL** — link shown in the update manager for more details - **Icon URL** — extension icon in update feeds ## Schema Reference Fields align with the moko-platform manifest schema at: And the existing structure in repos. ## Implementation Plan 1. **Model**: Add table (or extend existing ) with the above fields 2. **Router**: handler in 3. **Template**: with form fields 4. **Navbar**: Add tab to 5. **Integration**: Update and to read these settings when generating feeds ## UI Mockup Settings > Update Feed tab with sections: - **Identity**: Display name, description, icon URL, info URL - **Platform**: Type selector (Joomla/Dolibarr/Both), minimum version, extension type - **Joomla-specific** (shown when platform includes Joomla): element, folder, client (site/admin) - **Versioning**: Version format pattern, channel mapping rules ## Related - #239 (update server feature — this adds the settings UI for it) - #304 (permissions — uses TypeLicenses unit, this would need similar access control) --- *— Claude Opus 4.6 (1M context) <noreply@anthropic.com>*
jmiller commented 2026-06-06 13:45:34 +00:00
Author
Owner
Copy Link
Copy Source

Updated Scope: Auto-detect and migrate manifest.xml

In addition to the repo settings UI described above, this feature should:

1. Auto-detect .mokogitea/manifest.xml

On repo load (or settings page visit), detect if a .mokogitea/manifest.xml file exists in the repository root. If found:

  • Parse the XML and extract all settings (display name, platform type, extension type, folder/element, info URL, etc.)
  • Store these values in the repo settings database (the update_stream_config table or equivalent)
  • Delete the .mokogitea/manifest.xml file from the repo via a commit (automated migration)

2. Prevent duplicate settings

If a manifest.xml setting already maps to an existing field elsewhere (e.g. org-level custom fields, update_stream_config columns), do NOT create a duplicate:

  • Map manifest fields to their canonical storage location
  • If the canonical field already has a value, skip (don't overwrite)
  • If the canonical field is empty, populate it from the manifest
  • Log which fields were migrated vs skipped

3. Repo Settings Menu Item

Add a "Manifest" or "Update Feed" item in the repo settings navbar that shows the current values (whether migrated from manifest.xml or set manually) and allows editing.

Authored by Jonathan Miller (@jmiller)

## Updated Scope: Auto-detect and migrate manifest.xml In addition to the repo settings UI described above, this feature should: ### 1. Auto-detect .mokogitea/manifest.xml On repo load (or settings page visit), detect if a `.mokogitea/manifest.xml` file exists in the repository root. If found: - Parse the XML and extract all settings (display name, platform type, extension type, folder/element, info URL, etc.) - Store these values in the repo settings database (the update_stream_config table or equivalent) - Delete the `.mokogitea/manifest.xml` file from the repo via a commit (automated migration) ### 2. Prevent duplicate settings If a manifest.xml setting already maps to an existing field elsewhere (e.g. org-level custom fields, update_stream_config columns), do NOT create a duplicate: - Map manifest fields to their canonical storage location - If the canonical field already has a value, skip (don't overwrite) - If the canonical field is empty, populate it from the manifest - Log which fields were migrated vs skipped ### 3. Repo Settings Menu Item Add a "Manifest" or "Update Feed" item in the repo settings navbar that shows the current values (whether migrated from manifest.xml or set manually) and allows editing. --- *Authored by Jonathan Miller (@jmiller)*
jmiller commented 2026-06-06 13:52:38 +00:00
Author
Owner
Copy Link
Copy Source

Expanded Scope: API + CLI + Actions integration

Building on the previous comment, this feature must also:

4. API Endpoints for Manifest Settings

Expose manifest settings via REST API so that Actions workflows and the moko-platform CLI can read/write them:

  • GET /api/v1/repos/{owner}/{repo}/manifest — read current manifest settings
  • PUT /api/v1/repos/{owner}/{repo}/manifest — update manifest settings

This is critical because Actions and the moko-platform CLI will use these extensively for:

  • Auto-bumping version numbers in CI
  • Reading platform/language metadata for build matrix decisions
  • Setting extension metadata during release workflows
  • Syncing manifest settings across repos via moko-platform bulk operations

5. moko-platform CLI Update

The moko-platform CLI needs to be updated to:

  • Read manifest settings from the API instead of the manifest.xml file
  • Write manifest settings via the API (e.g. moko manifest set version 06.00.00)
  • Support moko manifest migrate to trigger migration of legacy manifest.xml files
  • Support moko manifest sync to push settings across multiple repos

This is tracked separately in the moko-platform repo.

Authored by Jonathan Miller (@jmiller)

## Expanded Scope: API + CLI + Actions integration Building on the previous comment, this feature must also: ### 4. API Endpoints for Manifest Settings Expose manifest settings via REST API so that Actions workflows and the moko-platform CLI can read/write them: - `GET /api/v1/repos/{owner}/{repo}/manifest` — read current manifest settings - `PUT /api/v1/repos/{owner}/{repo}/manifest` — update manifest settings This is critical because Actions and the moko-platform CLI will use these extensively for: - Auto-bumping version numbers in CI - Reading platform/language metadata for build matrix decisions - Setting extension metadata during release workflows - Syncing manifest settings across repos via moko-platform bulk operations ### 5. moko-platform CLI Update The moko-platform CLI needs to be updated to: - Read manifest settings from the API instead of the manifest.xml file - Write manifest settings via the API (e.g. `moko manifest set version 06.00.00`) - Support `moko manifest migrate` to trigger migration of legacy manifest.xml files - Support `moko manifest sync` to push settings across multiple repos This is tracked separately in the moko-platform repo. --- *Authored by Jonathan Miller (@jmiller)*
jmiller commented 2026-06-06 14:26:23 +00:00
Author
Owner
Copy Link
Copy Source

Testing Complete

Tested on dev (git.dev.mokoconsulting.tech) with testadmin/tab-test repo.

Test Result
Settings page renders with Identity/Governance/Build sections PASS
Manifest nav item active in repo settings navbar PASS
Values pre-filled from DB (version, license SPDX) PASS
API GET /repos/{owner}/{repo}/manifest returns saved values PASS
API PUT updates and persists manifest settings PASS
GET after PUT confirms persistence PASS
Form POST from settings page saves correctly PASS

Merged to dev via PR #504.

Authored by Jonathan Miller (@jmiller)

## Testing Complete Tested on dev (git.dev.mokoconsulting.tech) with testadmin/tab-test repo. | Test | Result | |------|--------| | Settings page renders with Identity/Governance/Build sections | PASS | | Manifest nav item active in repo settings navbar | PASS | | Values pre-filled from DB (version, license SPDX) | PASS | | API GET /repos/{owner}/{repo}/manifest returns saved values | PASS | | API PUT updates and persists manifest settings | PASS | | GET after PUT confirms persistence | PASS | | Form POST from settings page saves correctly | PASS | Merged to dev via PR #504. --- *Authored by Jonathan Miller (@jmiller)*
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
 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
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/MokoGitea-APP#315
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?