LightAPI Config Profile Manifests

This repository contains portable ConfigProfile manifests for LightAPI product releases.

The manifests describe which config files and properties belong to a product config contract, and which product versions should link to that contract. They are source inputs for event-importer --generate-config-profiles.

What Belongs Here

• Public, product-level ConfigProfile manifests.
• Release-scoped mappings for LightAPI Java and Rust products.
• Example manifests and validation rules.
• Schema and workflow files that keep manifests consistent.

What Does Not Belong Here

• Generated CloudEvents.
• Customer hostId, productVersionId, or admin user IDs.
• Tenant-specific overrides.
• Secrets or environment-specific config values.

Generated events are environment-specific and should be created locally by the portal operator.

Repository Layout

.
|-- examples/
|   `-- light-gateway-java-2.3.5.json
|-- java/
|   `-- <product-id>/<product-version>/manifest.json
|-- rust/
|   `-- <product-id>/<product-version>/manifest.json
|-- schema/
|   `-- config-profile-manifest.schema.json
`-- scripts/
    `-- validate-manifests.py

Use this path convention for real release manifests:

java/<product-id>/<product-version>/manifest.json
rust/<product-id>/<product-version>/manifest.json

Examples:

java/lg/2.3.5/manifest.json
rust/light-gateway/0.1.0/manifest.json

Manifest Contract

Each manifest has:

• runtimeFamily: usually java or rust.
• light4jVersion: optional framework version metadata.
• profiles: required array of reusable config contracts.
• products: optional array of product versions to link to profiles.

Minimal shape:

{
  "runtimeFamily": "java",
  "light4jVersion": "2.3.5",
  "profiles": [
    {
      "productId": "lg",
      "contractVersion": "2.3.5",
      "profileName": "light-gateway-java-2.3.5",
      "configs": [
        {
          "configName": "server.yml",
          "properties": "*"
        }
      ]
    }
  ],
  "products": [
    {
      "productId": "lg",
      "productVersion": "2.3.5",
      "configProfileRef": "lg|2.3.5"
    }
  ]
}

configs[].properties can be omitted, an empty array, or "*" to include all active properties for a config. It can also list property names explicitly:

{
  "configName": "handler.yml",
  "properties": ["enabled", "path"]
}

Product entries can use productVersionId when known, but public manifests should normally use productId plus productVersion so customers can resolve the product version inside their own portal database.

Generate Events

Run dry-run first:

java -jar target/event-importer.jar \
  --generate-config-profiles \
  --manifest java/lg/2.3.5/manifest.json \
  --targetHostId <customer-host-id> \
  --adminUserId <admin-user-id> \
  --output ./generated \
  --dry-run

Review generated/config-profile-dry-run.json.

Then generate event files:

java -jar target/event-importer.jar \
  --generate-config-profiles \
  --manifest java/lg/2.3.5/manifest.json \
  --targetHostId <customer-host-id> \
  --adminUserId <admin-user-id> \
  --output ./generated

When --output is a directory, event-importer writes:

• 07-config-profiles.json
• 08-config-profile-properties.json
• 09-config-profile-configs.json
• 10-product-version-config-profile-links.json

Import generated files in filename order.

Replacement Mode

Generation is additive by default. It will not generate delete events unless --replace is provided.

Use replacement mode only after a dry-run:

java -jar target/event-importer.jar \
  --generate-config-profiles \
  --manifest java/lg/2.3.5/manifest.json \
  --targetHostId <customer-host-id> \
  --adminUserId <admin-user-id> \
  --output ./generated \
  --dry-run \
  --replace

For replacement dry-runs, review:

• orphanedProfileMappings
• affectedProductVersions

These fields show which profile mappings would receive delete events and which active product versions are linked to the affected profiles.

Validate Manifests

Run local validation:

python3 scripts/validate-manifests.py

The validator checks all JSON files under examples/, java/, and rust/. GitHub Actions runs the same validation on pull requests.

Contributing

1. Add or update one manifest.json per product release.
2. Do not include customer-specific IDs or generated CloudEvents.
3. Run python3 scripts/validate-manifests.py.
4. Include the product release and config-contract change in the pull request description.

License

This repository is licensed under the Apache License 2.0. See LICENSE.