# Manifest Settings

The manifest settings feature provides a centralized way to store and manage project identity, governance, and build metadata for each repository. Settings are stored in the database and exposed via both a web UI and REST API.

## Overview

Each repository can have a manifest that describes:

- **Identity** — project name, organization, description, version, and license
- **Governance** — platform type, moko-platform standards version, and standards source URL
- **Build** — language, package type, and entry point

These settings replace the legacy `.mokogitea/manifest.xml` file-based approach.

## Repo Settings Page

Navigate to **Repository Settings > Manifest** to view and edit manifest fields.

| Section | Fields |
|---------|--------|
| Identity | Name, Org, Description, Version, License SPDX, License Name |
| Governance | Platform, Standards Version, Standards Source |
| Build | Language, Package Type, Entry Point |

### Auto-Migration from manifest.xml

On first visit to the Manifest settings page, if no manifest exists in the database but a `.mokogitea/manifest.xml` file exists in the repository, the system will:

1. Parse the XML and extract all fields
2. Store them in the database
3. Display a flash message indicating migration was successful
4. The manifest.xml file can then be manually deleted from the repository

If a field already has a value in the database (e.g., from org-level custom fields), the existing value is preserved and the manifest.xml value is skipped.

## REST API

The manifest API allows Actions workflows and the moko-platform CLI to read and write manifest settings programmatically.

### Get Manifest

```
GET /api/v1/repos/{owner}/{repo}/manifest
Authorization: token {access_token}
```

Returns the current manifest settings. If no manifest has been saved, returns defaults derived from repository metadata (name, owner, description).

**Response:**
```json
{
  "name": "MokoGitea",
  "org": "MokoConsulting",
  "description": "Moko fork of Gitea",
  "version": "06.04.00",
  "license_spdx": "GPL-3.0-or-later",
  "license_name": "GNU General Public License v3",
  "platform": "go",
  "standards_version": "05.00.00",
  "standards_source": "https://code.mokoconsulting.tech/MokoConsulting/moko-platform",
  "language": "Go",
  "package_type": "application",
  "entry_point": "./"
}
```

### Update Manifest

```
PUT /api/v1/repos/{owner}/{repo}/manifest
Authorization: token {access_token}
Content-Type: application/json
```

Requires repo admin permission. Accepts the same JSON structure as the GET response. Creates or updates the manifest.

### Usage in Actions Workflows

```yaml
steps:
  - name: Read manifest version
    run: |
      VERSION=$(curl -s "$GITEA_SERVER_URL/api/v1/repos/$GITHUB_REPOSITORY/manifest" \
        -H "Authorization: token ${{ secrets.GITEA_TOKEN }}" | jq -r '.version')
      echo "Current version: $VERSION"

  - name: Bump version
    run: |
      curl -s -X PUT "$GITEA_SERVER_URL/api/v1/repos/$GITHUB_REPOSITORY/manifest" \
        -H "Authorization: token ${{ secrets.GITEA_TOKEN }}" \
        -H "Content-Type: application/json" \
        -d "{\"version\": \"$NEW_VERSION\"}"
```

## Database

Manifest settings are stored in the `repo_manifest` table (migration v347). One row per repository, keyed by `repo_id`.

## Relationship to Other Systems

| System | Relationship |
|--------|-------------|
| Update Server | The update server generators read from both manifest settings and update_stream_config. Manifest provides identity metadata; update_stream_config provides feed-specific settings. |
| Custom Fields | Repo-scoped custom fields (org settings) are separate from manifest fields. Custom fields are user-defined; manifest fields follow the moko-platform schema. |
| moko-platform CLI | The CLI reads manifest settings via the API for version bumping, build decisions, and cross-repo syncing (see issue #505). |

---

| Revision | Date | Author | Description |
|---|---|---|---|
| 1.0 | 2026-06-06 | Jonathan Miller (@jmiller) | Initial version |
