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

feat: migrate update_stream_config metadata to org-level custom fields #492

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

Summary

Replace the hardcoded metadata columns in update_stream_config with org-level repo-scoped custom fields. The Update Server feed generator and all related workflows will read from custom field values instead of the dedicated config table columns.

Scope

This is a multi-phase migration that touches MokoGitea code, moko-platform workflows, and all Joomla/Dolibarr repo manifests.

Phase 1: Create Custom Fields for All Metadata

Add org-level repo-scoped custom fields matching the update_stream_config columns:

Custom Field Replaces Column Type
Platform platform dropdown: joomla, dolibarr, generic
Extension Name extension_name text
Display Name display_name text
Extension Type extension_type dropdown: package, plugin, module, component, template, library
Target Version target_version text
PHP Minimum php_minimum text
Support URL support_url url
Download Gating download_gating dropdown: none, prerelease, all
Key Prefix key_prefix text

Fields already created: Platform, Package Type (maps to Extension Type), Language, Entry Point, Standards Version

Fields still needed: Extension Name, Display Name, Target Version, PHP Minimum, Support URL, Download Gating, Key Prefix

Phase 2: Populate Values from Existing Config

For every repo with an update_stream_config row, copy the column values into the corresponding custom field values via SQL or API.

Phase 3: Update Feed Generator

Refactor services/updateserver/joomla.go (GenerateJoomlaXML) to read metadata from custom field values instead of UpdateStreamConfig:

// Before
cfg := licenses.GetEffectiveConfig(ctx, repo.OwnerID, repo.ID)
element := cfg.ExtensionName

// After
metadata, _ := issues_model.GetCustomFieldValuesMap(ctx, repo.ID)
element := metadata[fieldIDs.ExtensionName]

Same for Dolibarr, WordPress, Composer, PrestaShop, Drupal, WHMCS generators.

Phase 4: Update Licensing Settings UI

The repo Settings > Update Server page currently has form fields for extension_name, display_name, etc. These should be removed since the data now lives in Settings > Metadata.

Keep only licensing-specific settings in Update Server:

  • Enable Update Server (toggle)
  • Require Key (toggle)
  • Feed Visibility
  • Stream Mode / Custom Streams

Phase 5: Refactor moko-platform

Manifest Reader

  • cli/manifest_read.php currently reads .mokogitea/manifest.xml
  • Update to read from Gitea API: GET /api/v1/repos/{owner}/{repo}/metadata
  • Fall back to manifest.xml if API unavailable

Workflows

  • auto-release.yml uses manifest.xml for platform detection
  • Update to use Gitea API metadata endpoint
  • pr-check.yml validates manifest.xml format
  • Update to validate custom field values via API
  • repo-health.yml checks for manifest.xml presence
  • Update to check for metadata completeness via API

Bulk Sync

  • automation/sync-all-repos.sh pushes manifest.xml to all repos
  • Replace with API calls to set metadata custom fields

Phase 6: Remove Old Columns

Once all consumers are migrated:

  1. Remove columns from update_stream_config: extension_name, display_name, description, extension_type, maintainer, maintainer_url, info_url, target_version, php_minimum, support_url, key_prefix
  2. Remove corresponding form fields from templates
  3. Remove Go struct fields from UpdateStreamConfig
  4. Migration to drop columns

Phase 7: Deprecate manifest.xml

  • Remove .mokogitea/manifest.xml from all repos
  • Remove manifest.xml template from moko-platform
  • Update moko-platform standards docs
  • Remove manifest validation from pr-check workflow

Testing Checklist

  • All update XML feeds generate correctly from custom fields
  • Joomla update checker receives correct metadata
  • Repo Settings > Metadata page shows all fields
  • API GET/PUT metadata works for all repos
  • moko-platform workflows use API instead of manifest.xml
  • No regression in license key validation
  • No regression in download gating

Dependencies

  • #483 (org-level custom fields) - DONE
  • Custom fields API - DONE
  • Repo metadata settings page - DONE

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

## Summary Replace the hardcoded metadata columns in `update_stream_config` with org-level repo-scoped custom fields. The Update Server feed generator and all related workflows will read from custom field values instead of the dedicated config table columns. ## Scope This is a multi-phase migration that touches MokoGitea code, moko-platform workflows, and all Joomla/Dolibarr repo manifests. ## Phase 1: Create Custom Fields for All Metadata Add org-level repo-scoped custom fields matching the `update_stream_config` columns: | Custom Field | Replaces Column | Type | |---|---|---| | Platform | `platform` | dropdown: joomla, dolibarr, generic | | Extension Name | `extension_name` | text | | Display Name | `display_name` | text | | Extension Type | `extension_type` | dropdown: package, plugin, module, component, template, library | | Target Version | `target_version` | text | | PHP Minimum | `php_minimum` | text | | Support URL | `support_url` | url | | Download Gating | `download_gating` | dropdown: none, prerelease, all | | Key Prefix | `key_prefix` | text | Fields already created: Platform, Package Type (maps to Extension Type), Language, Entry Point, Standards Version Fields still needed: Extension Name, Display Name, Target Version, PHP Minimum, Support URL, Download Gating, Key Prefix ## Phase 2: Populate Values from Existing Config For every repo with an `update_stream_config` row, copy the column values into the corresponding custom field values via SQL or API. ## Phase 3: Update Feed Generator Refactor `services/updateserver/joomla.go` (`GenerateJoomlaXML`) to read metadata from custom field values instead of `UpdateStreamConfig`: ```go // Before cfg := licenses.GetEffectiveConfig(ctx, repo.OwnerID, repo.ID) element := cfg.ExtensionName // After metadata, _ := issues_model.GetCustomFieldValuesMap(ctx, repo.ID) element := metadata[fieldIDs.ExtensionName] ``` Same for Dolibarr, WordPress, Composer, PrestaShop, Drupal, WHMCS generators. ## Phase 4: Update Licensing Settings UI The repo Settings > Update Server page currently has form fields for extension_name, display_name, etc. These should be removed since the data now lives in Settings > Metadata. Keep only licensing-specific settings in Update Server: - Enable Update Server (toggle) - Require Key (toggle) - Feed Visibility - Stream Mode / Custom Streams ## Phase 5: Refactor moko-platform ### Manifest Reader - `cli/manifest_read.php` currently reads `.mokogitea/manifest.xml` - Update to read from Gitea API: `GET /api/v1/repos/{owner}/{repo}/metadata` - Fall back to manifest.xml if API unavailable ### Workflows - `auto-release.yml` uses manifest.xml for platform detection - Update to use Gitea API metadata endpoint - `pr-check.yml` validates manifest.xml format - Update to validate custom field values via API - `repo-health.yml` checks for manifest.xml presence - Update to check for metadata completeness via API ### Bulk Sync - `automation/sync-all-repos.sh` pushes manifest.xml to all repos - Replace with API calls to set metadata custom fields ## Phase 6: Remove Old Columns Once all consumers are migrated: 1. Remove columns from `update_stream_config`: extension_name, display_name, description, extension_type, maintainer, maintainer_url, info_url, target_version, php_minimum, support_url, key_prefix 2. Remove corresponding form fields from templates 3. Remove Go struct fields from `UpdateStreamConfig` 4. Migration to drop columns ## Phase 7: Deprecate manifest.xml - Remove `.mokogitea/manifest.xml` from all repos - Remove manifest.xml template from moko-platform - Update moko-platform standards docs - Remove manifest validation from pr-check workflow ## Testing Checklist - [ ] All update XML feeds generate correctly from custom fields - [ ] Joomla update checker receives correct metadata - [ ] Repo Settings > Metadata page shows all fields - [ ] API GET/PUT metadata works for all repos - [ ] moko-platform workflows use API instead of manifest.xml - [ ] No regression in license key validation - [ ] No regression in download gating ## Dependencies - #483 (org-level custom fields) - DONE - Custom fields API - DONE - Repo metadata settings page - DONE --- _Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>_
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
 pending: testing
Feature implemented but not yet tested with documented proof
 priority: critical
Must fix immediately
 priority: high
Important, fix soon
 priority: low
Nice to have
 priority: medium
Normal priority
 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
 status: blocked
Blocked by dependency or decision
 status: in-progress
Actively being worked on
 status: needs-review
Awaiting code review
 status: on-hold
Paused intentionally
 status: wontfix
Will not be addressed
 sync-failure
Sync or mirror failed
 tech-debt
Technical debt and TODO/FIXME items
 type: bug
Something isn't working
 type: bug
type: chore
Maintenance, dependencies, cleanup
 type: enhancement
Improvement to existing feature
 type: feature
New functionality
 type: refactor
Code restructuring without behavior change
 type: version
Version bump or release
 upstream
upstream
Inherited from upstream Gitea
 work-in-progress
Draft or incomplete work
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels
Status —
Type Feature
Status —
Priority —
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#492
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?