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

feat(updateserver): use repo_manifest as metadata source in feed generators #512

New Issue
Open
opened 2026-06-06 14:56:27 +00:00 by jmiller · 0 comments
jmiller commented 2026-06-06 14:56:27 +00:00
Owner
Copy Link
Copy Source

Summary

The update server feed generators (Joomla, WordPress, Dolibarr, etc.) should read from the repo_manifest table as an additional data source in the cascading fallback chain.

Current Priority Chain

  1. Custom field values (org-level repo-scoped fields)
  2. update_stream_config table
  3. Repo-derived defaults (name, description)

Proposed Priority Chain

  1. Custom field values (highest priority, user-defined)
  2. repo_manifest table (project identity metadata)
  3. update_stream_config table (feed-specific config)
  4. Repo-derived defaults (fallback)

Field Mapping

Manifest Field Feed Usage
name Extension element name fallback
description Feed description
version Version number for feeds
license_spdx License display in feeds
package_type Extension type (component, module, plugin, etc.)
language Used for build context

Implementation

Modify resolveExtensionMetadata() in services/updateserver/joomla.go (and equivalent functions in other generators) to query repo_manifest between custom fields and update_stream_config lookups.

Authored by Jonathan Miller (@jmiller)

## Summary The update server feed generators (Joomla, WordPress, Dolibarr, etc.) should read from the `repo_manifest` table as an additional data source in the cascading fallback chain. ## Current Priority Chain 1. Custom field values (org-level repo-scoped fields) 2. `update_stream_config` table 3. Repo-derived defaults (name, description) ## Proposed Priority Chain 1. Custom field values (highest priority, user-defined) 2. `repo_manifest` table (project identity metadata) 3. `update_stream_config` table (feed-specific config) 4. Repo-derived defaults (fallback) ## Field Mapping | Manifest Field | Feed Usage | |---------------|------------| | `name` | Extension element name fallback | | `description` | Feed description | | `version` | Version number for feeds | | `license_spdx` | License display in feeds | | `package_type` | Extension type (component, module, plugin, etc.) | | `language` | Used for build context | ## Implementation Modify `resolveExtensionMetadata()` in `services/updateserver/joomla.go` (and equivalent functions in other generators) to query `repo_manifest` between custom fields and update_stream_config lookups. --- *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#512
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?