Add helm charts for individual components#2820
Conversation
📝 WalkthroughWalkthroughThis PR adds three standalone Helm charts with Kubernetes resources, shared templating helpers, configurable values, local overrides, and TLS/autoscaling/persistence support. It also adds manual GitHub Actions workflows that package and publish each chart to GHCR as an OCI artifact. ChangesHelm chart suite
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/ai-workspace-ui-helm-release.ymlTraceback (most recent call last): .github/workflows/developer-portal-ui-helm-release.ymlTraceback (most recent call last): .github/workflows/platform-api-helm-release.ymlTraceback (most recent call last):
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Nitpick comments (4)
kubernetes/helm/ai-workspace-ui-helm-chart/templates/issuer.yaml (1)
3-21: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winDangling issuer reference when
createIssuer=truewith a non-Issuerkind.This template only creates the self-signed
IssuerwhenissuerRef.kind == "Issuer".certificate.yaml(L24-28) references{{ include "apip.aiWorkspace.fullname" . }}-selfsigned-issuerwhenevercreateIssueris true, regardless ofissuerRef.kind. If an operator setscreateIssuer: truewithissuerRef.kind: ClusterIssuer, no Issuer/ClusterIssuer is created but the Certificate still references the name — cert-manager will fail to issue silently, with no chart-level error surfaced. Consider afailguard here (or in certificate.yaml) whencreateIssueris true butissuerRef.kind != "Issuer".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@kubernetes/helm/ai-workspace-ui-helm-chart/templates/issuer.yaml` around lines 3 - 21, Update the issuer template guards around the self-signed issuer creation to validate that when $tls.certManager.createIssuer is true, $tls.certManager.issuerRef.kind is "Issuer"; otherwise fail Helm rendering with a clear configuration error. Preserve the existing issuer creation behavior for valid "Issuer" configurations.kubernetes/helm/ai-workspace-ui-helm-chart/templates/deployment.yaml (1)
106-107: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winNo guard against multi-replica scaling with in-memory sessions.
sessionStoredefaults tomemoryandhpa.minReplicasdefaults to 2 once HPA is enabled (values.yaml L106-108, L236). Nothing stops an operator from enablinghpawithout also changingsessionStore, silently breaking sessions once traffic is spread across replicas without sticky routing. Consider afailguard (mirroring thepodDisruptionBudgetmutual-exclusion check inpdb.yaml) whenhpa.enabledanddeployment.replicaCount/hpa.minReplicas> 1 whilesessionStore == "memory".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@kubernetes/helm/ai-workspace-ui-helm-chart/templates/deployment.yaml` around lines 106 - 107, The deployment template lacks a validation guard for multiple replicas using in-memory sessions. Add a Helm fail guard near the SESSION_STORE configuration that rejects sessionStore "memory" when hpa.enabled with hpa.minReplicas greater than 1 or deployment.replicaCount greater than 1, while allowing single-replica deployments and external session stores; mirror the established podDisruptionBudget validation pattern.kubernetes/helm/developer-portal-ui-helm-chart/templates/deployment.yaml (1)
27-27: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winStatic
replicasfights the HPA on everyhelm upgrade.When
hpa.enabledis true, keeping a staticreplicasfield on the Deployment causes Helm to reset the replica count to$deployment.replicaCounton every upgrade, overriding whatever the HPA had scaled to. Consider omittingreplicaswhen the HPA is enabled.♻️ Proposed fix
- replicas: {{ $deployment.replicaCount }} + {{- if not $dp.hpa.enabled }} + replicas: {{ $deployment.replicaCount }} + {{- end }}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@kubernetes/helm/developer-portal-ui-helm-chart/templates/deployment.yaml` at line 27, Update the Deployment template around the replicas field to render replicas only when the HPA is disabled; when hpa.enabled is true, omit the field so Helm does not reset the HPA-managed count during upgrades.kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl (1)
189-217: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy liftCross-chart secret helpers duplicated per chart — drift risk.
apip.aiWorkspace.secretName/apip.developerPortal.secretNamearen't called anywhere in this chart's own templates; they exist so the sibling ai-workspace/developer-portal charts can resolve secrets identically. Since Helm doesn't support sharing_helpers.tplacross independently-packaged charts, this whole file is likely copied verbatim into each of the three charts — any future fix (like thedefault truebug above) has to be applied in three places or they silently diverge.Consider extracting this into a Helm library chart shared as a dependency instead of copy-pasting
_helpers.tpl.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl` around lines 189 - 217, Extract the shared secret-name helpers, including apip.platformApi.secretName, apip.aiWorkspace.secretName, and apip.developerPortal.secretName, into a Helm library chart and declare it as a dependency of all three charts. Update each chart to consume the library helpers instead of maintaining copied definitions in its own _helpers.tpl, preserving the existing values lookup and required-secret validation behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ai-workspace-ui-helm-release.yml:
- Around line 58-59: Replace direct interpolation of inputs.appVersion in the
Helm release workflows with an environment-passed value, validate it against an
allowed version format, and update Chart.yaml without embedding untrusted input
in Bash source. Apply this change at
.github/workflows/ai-workspace-ui-helm-release.yml:58-59,
.github/workflows/developer-portal-ui-helm-release.yml:58-59, and
.github/workflows/platform-api-helm-release.yml:58-59.
- Around line 57-60: Update the release-source contract in
.github/workflows/ai-workspace-ui-helm-release.yml:57-60,
.github/workflows/developer-portal-ui-helm-release.yml:57-60, and
.github/workflows/platform-api-helm-release.yml:57-60 so the version and
optional appVersion used to publish each Helm chart are also represented in the
tagged source; either validate that requested inputs already match each chart’s
checked-in Chart.yaml metadata or commit the metadata changes before creating
the tag.
- Around line 49-52: Pin the Helm version instead of using latest in the Install
Helm step for .github/workflows/ai-workspace-ui-helm-release.yml lines 49-52,
.github/workflows/developer-portal-ui-helm-release.yml lines 49-52, and
.github/workflows/platform-api-helm-release.yml lines 49-52, using the same
explicit version across all three workflows.
In `@kubernetes/helm/.gitignore`:
- Around line 3-6: Update the ignore patterns in the Helm .gitignore to use the
actual ai-workspace-ui-helm-chart/ and developer-portal-ui-helm-chart/ directory
names, preserving both charts/ and Chart.lock exclusions so dependency-update
artifacts remain ignored.
In `@kubernetes/helm/ai-workspace-ui-helm-chart/values.yaml`:
- Around line 124-136: Change the default service.type from LoadBalancer to
ClusterIP in the service configuration, keeping external exposure as an explicit
operator opt-in while preserving the existing service settings and
development-mode defaults.
In `@kubernetes/helm/developer-portal-ui-helm-chart/templates/_helpers.tpl`:
- Around line 27-35: Update the fullname helpers apip.platformApi.fullname,
apip.aiWorkspace.fullname, and apip.developerPortal.fullname to truncate the
included apip.fullname base to the available length before appending each
component suffix, then trim any trailing hyphen. Preserve the distinct
platform-api, ai-workspace, and developer-portal suffixes in the generated
names.
In `@kubernetes/helm/developer-portal-ui-helm-chart/values-local.yaml`:
- Around line 2-3: Update the usage command in values-local.yaml to reference
values-local.yaml relative to the developer-portal-ui-helm-chart directory and
include the required secrets overlay file, so standalone Helm installation
renders successfully from the documented invocation.
In `@kubernetes/helm/developer-portal-ui-helm-chart/values.yaml`:
- Around line 19-20: Update the chart defaults in values.yaml so developmentMode
is false, role validation is enabled, and Platform API TLS verification is not
skipped; move only the development-specific overrides needed for local
development into values-local.yaml, preserving the existing configuration keys
and structure.
- Around line 150-161: Update the service defaults in values.yaml to use
ClusterIP instead of LoadBalancer, and add a default-off administrative opt-in
that gates NodePort and LoadBalancer exposure. Provide safe built-in
private-range source restrictions with configuration for operator extensions,
ensuring tenant values cannot widen exposure unless the explicit administrative
setting is enabled.
In `@kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl`:
- Around line 132-142: Update the tlsEnabled handling in
apip.platformApi.internalURL to distinguish an absent value from an explicit
false; retain true as the fallback only when global.platformApi.tlsEnabled is
unset, and pass the resulting boolean to ternary so false selects http.
In `@kubernetes/helm/platform-api-helm-chart/templates/certificate.yaml`:
- Around line 24-29: Reject incompatible createIssuer and issuerRef.kind
settings in certificate.yaml: when createIssuer is true, require issuerRef.kind
to be Issuer or force the generated Certificate reference to kind Issuer. Align
the rendering gate in
kubernetes/helm/platform-api-helm-chart/templates/issuer.yaml lines 3-4 with
this Certificate contract; update both sites accordingly.
In `@kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml`:
- Around line 18-33: Update the ConfigMap TOML emitted by the platform API
configuration template to use the 0.12.0 schema rooted under platform_api,
including nested database, auth.jwt, and server.http sections as expected by
config.go. Move the existing top-level keys into their corresponding
platform_api paths and ensure the service port is rendered as a numeric TOML
value rather than a quoted string. Preserve the current conditional PostgreSQL
fields while placing them under platform_api.database.
---
Nitpick comments:
In `@kubernetes/helm/ai-workspace-ui-helm-chart/templates/deployment.yaml`:
- Around line 106-107: The deployment template lacks a validation guard for
multiple replicas using in-memory sessions. Add a Helm fail guard near the
SESSION_STORE configuration that rejects sessionStore "memory" when hpa.enabled
with hpa.minReplicas greater than 1 or deployment.replicaCount greater than 1,
while allowing single-replica deployments and external session stores; mirror
the established podDisruptionBudget validation pattern.
In `@kubernetes/helm/ai-workspace-ui-helm-chart/templates/issuer.yaml`:
- Around line 3-21: Update the issuer template guards around the self-signed
issuer creation to validate that when $tls.certManager.createIssuer is true,
$tls.certManager.issuerRef.kind is "Issuer"; otherwise fail Helm rendering with
a clear configuration error. Preserve the existing issuer creation behavior for
valid "Issuer" configurations.
In `@kubernetes/helm/developer-portal-ui-helm-chart/templates/deployment.yaml`:
- Line 27: Update the Deployment template around the replicas field to render
replicas only when the HPA is disabled; when hpa.enabled is true, omit the field
so Helm does not reset the HPA-managed count during upgrades.
In `@kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl`:
- Around line 189-217: Extract the shared secret-name helpers, including
apip.platformApi.secretName, apip.aiWorkspace.secretName, and
apip.developerPortal.secretName, into a Helm library chart and declare it as a
dependency of all three charts. Update each chart to consume the library helpers
instead of maintaining copied definitions in its own _helpers.tpl, preserving
the existing values lookup and required-secret validation behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 6a1180d3-1489-4241-8faf-332123d1a1c7
📒 Files selected for processing (42)
.github/workflows/ai-workspace-ui-helm-release.yml.github/workflows/developer-portal-ui-helm-release.yml.github/workflows/platform-api-helm-release.ymlkubernetes/helm/.gitignorekubernetes/helm/ai-workspace-ui-helm-chart/.helmignorekubernetes/helm/ai-workspace-ui-helm-chart/Chart.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/_helpers.tplkubernetes/helm/ai-workspace-ui-helm-chart/templates/certificate.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/configmap.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/deployment.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/hpa.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/issuer.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/pdb.yamlkubernetes/helm/ai-workspace-ui-helm-chart/templates/service.yamlkubernetes/helm/ai-workspace-ui-helm-chart/values-local.yamlkubernetes/helm/ai-workspace-ui-helm-chart/values.yamlkubernetes/helm/developer-portal-ui-helm-chart/.helmignorekubernetes/helm/developer-portal-ui-helm-chart/Chart.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/_helpers.tplkubernetes/helm/developer-portal-ui-helm-chart/templates/certificate.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/configmap.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/deployment.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/hpa.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/issuer.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/pdb.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/pvc.yamlkubernetes/helm/developer-portal-ui-helm-chart/templates/service.yamlkubernetes/helm/developer-portal-ui-helm-chart/values-local.yamlkubernetes/helm/developer-portal-ui-helm-chart/values.yamlkubernetes/helm/platform-api-helm-chart/.helmignorekubernetes/helm/platform-api-helm-chart/Chart.yamlkubernetes/helm/platform-api-helm-chart/templates/_helpers.tplkubernetes/helm/platform-api-helm-chart/templates/certificate.yamlkubernetes/helm/platform-api-helm-chart/templates/configmap.yamlkubernetes/helm/platform-api-helm-chart/templates/deployment.yamlkubernetes/helm/platform-api-helm-chart/templates/hpa.yamlkubernetes/helm/platform-api-helm-chart/templates/issuer.yamlkubernetes/helm/platform-api-helm-chart/templates/pdb.yamlkubernetes/helm/platform-api-helm-chart/templates/pvc.yamlkubernetes/helm/platform-api-helm-chart/templates/service.yamlkubernetes/helm/platform-api-helm-chart/values-local.yamlkubernetes/helm/platform-api-helm-chart/values.yaml
| - name: Install Helm | ||
| uses: azure/setup-helm@v4 | ||
| with: | ||
| version: 'latest' |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Tracked workflow files matching helm-release:\n'
git ls-files '.github/workflows/*helm-release.yml' || true
printf '\nRelevant action inputs:\n'
for f in $(git ls-files '.github/workflows/*helm-release.yml'); do
echo "--- $f"
nl -ba "$f" | sed -n '40,60p'
done
printf '\nSearch for Helm version references:\n'
rg -n "azure/setup-helm|version: ['\"]latest['\"]|helm (version|package|push)|Helm" .github/workflows README.md 2>/dev/null || trueRepository: wso2/api-platform
Length of output: 612
🌐 Web query:
azure/setup-helm version input latest semver alias GitHub Action documentation
💡 Result:
The azure/setup-helm GitHub Action manages the version of Helm to be installed on a runner primarily through the version input [1][2]. Key details regarding the version input: - Acceptable values: You can provide either the string latest or a specific semantic version string (e.g., v3.5.0) [1][3]. - Default behavior: The input defaults to latest, which instructs the action to fetch the most recent stable release of Helm [1][2][4]. - Fallback mechanism: If the action fails to fetch the latest version, it automatically falls back to a hardcoded "safe" default version (a specific version which is updated periodically in the action's source code) [1][3][4]. - Version file support: Alternatively, you can use the version-file input to point to a .tool-versions file (commonly used by asdf or mise), which allows the action to parse the desired version [1][5]. If both version and version-file are provided, the explicit version input takes precedence [1][5]. There is no native "semver alias" feature for the version input; you must either explicitly define the version (e.g., v3.18.4) or use latest [1][2]. If you require a specific version and wish to avoid the potential fallback to the hardcoded default, it is recommended to explicitly specify that version rather than relying on latest [1][3].
Citations:
- 1: https://github.com/Azure/setup-helm/blob/main/README.md
- 2: https://github.com/Azure/setup-helm/blob/master/action.yml
- 3: https://github.com/Azure/setup-helm
- 4: Bug: Default Helm version v3.18.4 is not applied when no version input is provided; v4.0.1 is installed instead Azure/setup-helm#241
- 5: Add version-file input to read the Helm version from a .tool-versions file Azure/setup-helm#281
🏁 Script executed:
#!/bin/bash
set -euo pipefail
for f in $(git ls-files '.github/workflows/*helm-release.yml'); do
echo "--- $f"
awk 'NR>=45 && NR<=55 {printf "%5d\t%s\n", NR, $0}' "$f"
done
echo "--- version/azure/setup-helm references ---"
grep -nE "azure/setup-helm|version:\s*['\"]?latest|helm version|helm package|helm push" .github/workflows || trueRepository: wso2/api-platform
Length of output: 3359
🏁 Script executed:
#!/bin/bash
set -euo pipefail
grep -RnE "azure/setup-helm|version:\s*['\"]?latest|helm (version|package|push)" .github/workflows || trueRepository: wso2/api-platform
Length of output: 3208
Pin the Helm version used for chart releases. latest leaves chart packaging and OCI upload behavior outside source control.
.github/workflows/ai-workspace-ui-helm-release.yml#L49-L52.github/workflows/developer-portal-ui-helm-release.yml#L49-L52.github/workflows/platform-api-helm-release.yml#L49-L52
📍 Affects 3 files
.github/workflows/ai-workspace-ui-helm-release.yml#L49-L52(this comment).github/workflows/developer-portal-ui-helm-release.yml#L49-L52.github/workflows/platform-api-helm-release.yml#L49-L52
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ai-workspace-ui-helm-release.yml around lines 49 - 52, Pin
the Helm version instead of using latest in the Install Helm step for
.github/workflows/ai-workspace-ui-helm-release.yml lines 49-52,
.github/workflows/developer-portal-ui-helm-release.yml lines 49-52, and
.github/workflows/platform-api-helm-release.yml lines 49-52, using the same
explicit version across all three workflows.
| sed -i "s/^version:.*/version: ${CHART_VERSION}/" Chart.yaml | ||
| if [ -n "${{ inputs.appVersion }}" ]; then | ||
| sed -i "s/^appVersion:.*/appVersion: \"${{ inputs.appVersion }}\"/" Chart.yaml | ||
| fi |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Make the tagged source match the published chart. These edits exist only in the runner, so a tag for an input version different from the checked-in version cannot reproduce the OCI artifact.
.github/workflows/ai-workspace-ui-helm-release.yml#L57-L60: either require the requested version to already matchChart.yaml, or commit the metadata update before creating the tag..github/workflows/developer-portal-ui-helm-release.yml#L57-L60: apply the same release-source contract..github/workflows/platform-api-helm-release.yml#L57-L60: apply the same release-source contract.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 58-58: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
[error] 59-59: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
📍 Affects 3 files
.github/workflows/ai-workspace-ui-helm-release.yml#L57-L60(this comment).github/workflows/developer-portal-ui-helm-release.yml#L57-L60.github/workflows/platform-api-helm-release.yml#L57-L60
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ai-workspace-ui-helm-release.yml around lines 57 - 60,
Update the release-source contract in
.github/workflows/ai-workspace-ui-helm-release.yml:57-60,
.github/workflows/developer-portal-ui-helm-release.yml:57-60, and
.github/workflows/platform-api-helm-release.yml:57-60 so the version and
optional appVersion used to publish each Helm chart are also represented in the
tagged source; either validate that requested inputs already match each chart’s
checked-in Chart.yaml metadata or commit the metadata changes before creating
the tag.
| if [ -n "${{ inputs.appVersion }}" ]; then | ||
| sed -i "s/^appVersion:.*/appVersion: \"${{ inputs.appVersion }}\"/" Chart.yaml |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not splice appVersion into Bash source. A quote or command substitution in the dispatch input is parsed by the runner before sed executes; this workflow has contents: write and packages: write.
.github/workflows/ai-workspace-ui-helm-release.yml#L58-L59: pass the input throughenv, validate it against an allowed version format, then update YAML without source interpolation..github/workflows/developer-portal-ui-helm-release.yml#L58-L59: apply the same input handling..github/workflows/platform-api-helm-release.yml#L58-L59: apply the same input handling.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 58-58: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
[error] 59-59: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
📍 Affects 3 files
.github/workflows/ai-workspace-ui-helm-release.yml#L58-L59(this comment).github/workflows/developer-portal-ui-helm-release.yml#L58-L59.github/workflows/platform-api-helm-release.yml#L58-L59
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ai-workspace-ui-helm-release.yml around lines 58 - 59,
Replace direct interpolation of inputs.appVersion in the Helm release workflows
with an environment-passed value, validate it against an allowed version format,
and update Chart.yaml without embedding untrusted input in Bash source. Apply
this change at .github/workflows/ai-workspace-ui-helm-release.yml:58-59,
.github/workflows/developer-portal-ui-helm-release.yml:58-59, and
.github/workflows/platform-api-helm-release.yml:58-59.
Source: Linters/SAST tools
| ai-workspace-helm-chart/charts/ | ||
| ai-workspace-helm-chart/Chart.lock | ||
| developer-portal-helm-chart/charts/ | ||
| developer-portal-helm-chart/Chart.lock |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Chart directory names don't match actual chart paths — ignore rules are dead.
These patterns target ai-workspace-helm-chart/ and developer-portal-helm-chart/, but the actual chart directories in this PR are ai-workspace-ui-helm-chart/ and developer-portal-ui-helm-chart/ (missing -ui-). As written, helm dependency update output (vendored charts/ archives and Chart.lock) in those directories won't be ignored and can get committed.
🔧 Proposed fix
-ai-workspace-helm-chart/charts/
-ai-workspace-helm-chart/Chart.lock
-developer-portal-helm-chart/charts/
-developer-portal-helm-chart/Chart.lock
+ai-workspace-ui-helm-chart/charts/
+ai-workspace-ui-helm-chart/Chart.lock
+developer-portal-ui-helm-chart/charts/
+developer-portal-ui-helm-chart/Chart.lock📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ai-workspace-helm-chart/charts/ | |
| ai-workspace-helm-chart/Chart.lock | |
| developer-portal-helm-chart/charts/ | |
| developer-portal-helm-chart/Chart.lock | |
| ai-workspace-ui-helm-chart/charts/ | |
| ai-workspace-ui-helm-chart/Chart.lock | |
| developer-portal-ui-helm-chart/charts/ | |
| developer-portal-ui-helm-chart/Chart.lock |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/.gitignore` around lines 3 - 6, Update the ignore patterns in
the Helm .gitignore to use the actual ai-workspace-ui-helm-chart/ and
developer-portal-ui-helm-chart/ directory names, preserving both charts/ and
Chart.lock exclusions so dependency-update artifacts remain ignored.
There was a problem hiding this comment.
These are generated when we run helm dependency update command which will be only executed in ai-workspace-helm-chart and developer-portal-helm-chart. That's why these are ignored
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '== Helm chart directories =='
fd -t d -d 1 --glob '*helm-chart' kubernetes/helm | sort
printf '%s\n' '== Chart.yaml files containing dependencies =='
for chart in $(fd -t f -d 2 '^Chart\.yaml$' kubernetes/helm | sort); do
if rg -n -C 2 '^dependencies:' "$chart"; then
printf '%s\n' "-- $chart"
fi
done
printf '%s\n' '== Current Helm .gitignore =='
cat -n kubernetes/helm/.gitignoreLength of output: 1434
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '== Tracked paths matching the claimed umbrella names =='
git ls-files | rg -n '(?:^|/)(ai-workspace-helm-chart|developer-portal-helm-chart)(?:/|$)' || true
printf '%s\n' '== References to the claimed umbrella names =='
rg -n -C 2 '(?:ai-workspace-helm-chart|developer-portal-helm-chart)' . \
-g '!**/.git/**' || true
printf '%s\n' '== Helm dependency update invocations =='
rg -n -C 3 '\bhelm\s+dependency\s+update\b' . \
-g '!**/.git/**' || trueLength of output: 781
@DinithHerath, I checked the PR branch: neither ai-workspace-helm-chart/ nor developer-portal-helm-chart/ exists in tracked paths, and neither name nor a helm dependency update invocation appears anywhere in the repository.
So the explanation does not currently substantiate these ignore rules. If those umbrella charts are intended to be added separately, retaining the patterns is fine but the comment is misleading in this PR; otherwise, the patterns should target the existing *-ui-helm-chart directories. I’ll keep the finding open based on the checked-in layout.
| service: | ||
| type: LoadBalancer # LoadBalancer | NodePort | ClusterIP | ||
| annotations: {} | ||
| labels: {} | ||
| port: 5380 | ||
| clusterIP: "" | ||
| externalTrafficPolicy: "" | ||
| loadBalancerClass: "" | ||
| loadBalancerSourceRanges: [] | ||
| ipFamilyPolicy: "" | ||
| ipFamilies: [] | ||
| nodePort: "" | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Risky default: public LoadBalancer Service combined with default basic-auth dev credentials.
service.type defaults to LoadBalancer while config.authMode defaults to basic, which per the comment at L61 means the Platform API's file-based login (admin/admin in dev). Installing this chart standalone with defaults provisions an internet-facing load balancer fronting a UI backed by default dev credentials. Consider defaulting service.type to ClusterIP and letting operators opt in to external exposure explicitly, especially since global.developmentMode: true is also the standalone default.
🛡️ Proposed default change
service:
- type: LoadBalancer # LoadBalancer | NodePort | ClusterIP
+ type: ClusterIP # LoadBalancer | NodePort | ClusterIP📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| service: | |
| type: LoadBalancer # LoadBalancer | NodePort | ClusterIP | |
| annotations: {} | |
| labels: {} | |
| port: 5380 | |
| clusterIP: "" | |
| externalTrafficPolicy: "" | |
| loadBalancerClass: "" | |
| loadBalancerSourceRanges: [] | |
| ipFamilyPolicy: "" | |
| ipFamilies: [] | |
| nodePort: "" | |
| service: | |
| type: ClusterIP # LoadBalancer | NodePort | ClusterIP | |
| annotations: {} | |
| labels: {} | |
| port: 5380 | |
| clusterIP: "" | |
| externalTrafficPolicy: "" | |
| loadBalancerClass: "" | |
| loadBalancerSourceRanges: [] | |
| ipFamilyPolicy: "" | |
| ipFamilies: [] | |
| nodePort: "" |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/ai-workspace-ui-helm-chart/values.yaml` around lines 124 -
136, Change the default service.type from LoadBalancer to ClusterIP in the
service configuration, keeping external exposure as an explicit operator opt-in
while preserving the existing service settings and development-mode defaults.
There was a problem hiding this comment.
Since we explicitly ship with developmentMode turned on it is recommended to switch these off when we are going to production
There was a problem hiding this comment.
@DinithHerath, understood. Turning off developmentMode for production is necessary, but it does not change the default service.type: LoadBalancer; operators must separately override the service configuration to avoid external exposure.
I therefore still recommend ClusterIP as the chart default, with LoadBalancer explicitly enabled in production configurations that need it. If the standalone chart is intentionally optimized for development convenience, documenting the required production overrides prominently would also help.
| global: | ||
| developmentMode: true |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Move development-only security settings into values-local.yaml.
The standalone chart defaults to development mode, disables role validation, and skips Platform API TLS verification. A default install therefore weakens authorization and permits an in-cluster Platform API impersonation path. Default these to false/true/false respectively, then add only required local overrides to values-local.yaml.
Proposed baseline
global:
- developmentMode: true
+ developmentMode: false
...
security:
- roleValidation: false
+ roleValidation: true
...
platformApi:
- insecure: true
+ insecure: falseAlso applies to: 84-85, 98-101
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/developer-portal-ui-helm-chart/values.yaml` around lines 19 -
20, Update the chart defaults in values.yaml so developmentMode is false, role
validation is enabled, and Platform API TLS verification is not skipped; move
only the development-specific overrides needed for local development into
values-local.yaml, preserving the existing configuration keys and structure.
| service: | ||
| type: LoadBalancer # LoadBalancer | NodePort | ClusterIP | ||
| annotations: {} | ||
| labels: {} | ||
| port: 3000 | ||
| clusterIP: "" | ||
| externalTrafficPolicy: "" | ||
| loadBalancerClass: "" | ||
| loadBalancerSourceRanges: [] | ||
| ipFamilyPolicy: "" | ||
| ipFamilies: [] | ||
| nodePort: "" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Make external exposure an administrator-only opt-in.
LoadBalancer with empty loadBalancerSourceRanges has no chart-level client restriction, while tenant-supplied values can expose it further. Default to ClusterIP (or a private-only policy), and gate NodePort/LoadBalancer behind an explicit, default-off administrative setting. Kubernetes uses loadBalancerSourceRanges to restrict client IPs only when the platform supports it. (kubernetes.io)
As per coding guidelines, “Use safe built-in private-range denylist defaults, permit operator extensions through configuration, and do not allow tenant configuration to widen exceptions unless an explicit administrative opt-in is enabled by default off.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/developer-portal-ui-helm-chart/values.yaml` around lines 150
- 161, Update the service defaults in values.yaml to use ClusterIP instead of
LoadBalancer, and add a default-off administrative opt-in that gates NodePort
and LoadBalancer exposure. Provide safe built-in private-range source
restrictions with configuration for operator extensions, ensuring tenant values
cannot widen exposure unless the explicit administrative setting is enabled.
Source: Coding guidelines
| {{/* | ||
| Default in-cluster URL portals use to reach the shared Platform API. Scheme and | ||
| port come from global.platformApi so portals need not read the platform-api | ||
| subchart's own values. | ||
| */}} | ||
| {{- define "apip.platformApi.internalURL" -}} | ||
| {{- $g := default (dict) .Values.global -}} | ||
| {{- $pa := default (dict) $g.platformApi -}} | ||
| {{- $scheme := ternary "https" "http" (default true $pa.tlsEnabled) -}} | ||
| {{- printf "%s://%s:%d" $scheme (include "apip.platformApi.fullname" .) (int (default 9243 $pa.port)) -}} | ||
| {{- end -}} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Sprig template function default treats false as empty value
💡 Result:
Yes, the Sprig template function 'default' treats a boolean 'false' value as empty, meaning it will trigger the use of the provided default value [1][2][3]. In the Sprig library, the 'default' function is designed to return a specified default value if the input variable is considered "empty" [1][2]. The definition of "empty" in Sprig is intentionally broad and consistent with how Go's 'text/template' package evaluates truthiness [3][4][5]. Specifically, Sprig considers the following as empty: - Booleans: 'false' [1][2][3] - Numeric types: '0' [1][2][3] - Strings: "" (empty string) [1][2][3] - Lists: '[]' (empty slice/array) [1][2][3] - Dictionaries: '{}' (empty map) [1][2][3] - Null/Nil values [1][2][3] Because 'false' is categorized as an empty value, using '{{ default "fallback" false }}' will return '"fallback"' rather than 'false' [6][7]. This behavior is a known design choice in Sprig and 'text/template' [3][6][5], though it is frequently identified as a point of confusion for users who wish to pass 'false' as a legitimate, non-defaulted value [8][6][7]. To circumvent this, users often implement custom template logic or helper functions [6][7]. For example, one common workaround involves using an 'if' block to check the type or value before applying a default, or using alternative logic that distinguishes between an "unset" variable and a variable explicitly set to 'false' [6].
Citations:
- 1: https://github.com/Masterminds/sprig/blob/master/docs/defaults.md
- 2: http://masterminds.github.io/sprig/defaults.html
- 3: https://github.com/Masterminds/sprig/blob/v2.22.0/defaults.go
- 4: https://github.com/Masterminds/sprig/blob/master/defaults.go
- 5: https://gobyexample.com/text-templates
- 6: default true false triggers the default value Masterminds/sprig#111
- 7: default function treats boolean false as not defined, and applies default helm/helm#3308
- 8: Default function evaluating the default value when the value provided is not omitted helm/helm#12781
🌐 Web query:
Sprig default function implementation Go empty value false reflection
💡 Result:
In the Sprig library for Go, the default function is explicitly designed to treat boolean false as an empty value [1][2][3]. Consequently, when you provide false as the input to be tested, the default function will ignore it and return the specified default value [4][5]. Implementation Details The behavior is controlled by the internal empty function, which uses Go reflection to determine if a value is considered empty [1][2]. The implementation for the boolean type is as follows: case reflect.Bool: return!g.Bool Because the function returns true when the value is false, the default function interprets false as empty, triggering the fallback mechanism [1][2][6]. Why this happens The Sprig documentation clarifies that for booleans, false is considered empty [7][3]. This is a long-standing behavior that intentionally treats "empty" or "zero" values (like 0 for numbers, "" for strings, and false for booleans) as values that should be overridden by a default [1][3]. Workarounds Because this behavior is deeply embedded in the library, it cannot be changed without breaking existing implementations [8]. Common workarounds include: 1. Conditional Checks: Instead of using default, use an if-block to check the value explicitly if you need to distinguish between a missing value and a false value. 2. Custom Helper Functions: Define a custom template function that checks for nil or specific conditions rather than using Sprig's default [5]. For example: {{- define "defaultBool" -}} {{- if typeIs "bool". -}} {{-. -}} {{- else -}} {{- default true. -}} {{- end -}} {{- end -}} This allows you to treat booleans differently while retaining default behavior for other types [5].
Citations:
- 1: https://github.com/Masterminds/sprig/blob/master/defaults.go
- 2: https://github.com/Masterminds/sprig/blob/v2.22.0/defaults.go
- 3: http://masterminds.github.io/sprig/defaults.html
- 4: Default function evaluating the default value when the value provided is not omitted helm/helm#12781
- 5: default true false triggers the default value Masterminds/sprig#111
- 6: https://github.com/go-task/slim-sprig/blob/master/defaults.go
- 7: https://github.com/Masterminds/sprig/blob/master/docs/defaults.md
- 8: default function treats boolean false as not defined, and applies default helm/helm#3308
Preserve an explicit global.platformApi.tlsEnabled: false.
Sprig’s default treats false as empty, so default true $pa.tlsEnabled replaces an explicitly configured plaintext request with https. Use presence-checked logic for the boolean instead of default.
🔧 Proposed fix
-{{- $scheme := ternary "https" "http" (default true $pa.tlsEnabled) -}}
+{{- $tlsEnabled := true -}}
+{{- if hasKey $pa "tlsEnabled" -}}
+{{- $tlsEnabled = $pa.tlsEnabled -}}
+{{- end -}}
+{{- $scheme := ternary "https" "http" $tlsEnabled -}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{/* | |
| Default in-cluster URL portals use to reach the shared Platform API. Scheme and | |
| port come from global.platformApi so portals need not read the platform-api | |
| subchart's own values. | |
| */}} | |
| {{- define "apip.platformApi.internalURL" -}} | |
| {{- $g := default (dict) .Values.global -}} | |
| {{- $pa := default (dict) $g.platformApi -}} | |
| {{- $scheme := ternary "https" "http" (default true $pa.tlsEnabled) -}} | |
| {{- printf "%s://%s:%d" $scheme (include "apip.platformApi.fullname" .) (int (default 9243 $pa.port)) -}} | |
| {{- end -}} | |
| {{/* | |
| Default in-cluster URL portals use to reach the shared Platform API. Scheme and | |
| port come from global.platformApi so portals need not read the platform-api | |
| subchart's own values. | |
| */}} | |
| {{- define "apip.platformApi.internalURL" -}} | |
| {{- $g := default (dict) .Values.global -}} | |
| {{- $pa := default (dict) $g.platformApi -}} | |
| {{- $tlsEnabled := true -}} | |
| {{- if hasKey $pa "tlsEnabled" -}} | |
| {{- $tlsEnabled = $pa.tlsEnabled -}} | |
| {{- end -}} | |
| {{- $scheme := ternary "https" "http" $tlsEnabled -}} | |
| {{- printf "%s://%s:%d" $scheme (include "apip.platformApi.fullname" .) (int (default 9243 $pa.port)) -}} | |
| {{- end -}} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl` around lines
132 - 142, Update the tlsEnabled handling in apip.platformApi.internalURL to
distinguish an absent value from an explicit false; retain true as the fallback
only when global.platformApi.tlsEnabled is unset, and pass the resulting boolean
to ternary so false selects http.
| {{- if $tls.certManager.createIssuer }} | ||
| name: {{ include "apip.platformApi.fullname" . }}-selfsigned-issuer | ||
| {{- else }} | ||
| name: {{ $tls.certManager.issuerRef.name }} | ||
| {{- end }} | ||
| kind: {{ $tls.certManager.issuerRef.kind }} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Reject incompatible createIssuer and issuer-kind settings. A ClusterIssuer with createIssuer: true makes the Certificate reference a self-signed ClusterIssuer that this chart never creates; the Issuer template only renders for kind Issuer.
kubernetes/helm/platform-api-helm-chart/templates/certificate.yaml#L24-L29: fail rendering unlesscreateIssueris paired withissuerRef.kind: Issuer, or force the matching kind.kubernetes/helm/platform-api-helm-chart/templates/issuer.yaml#L3-L4: keep its gate aligned with the Certificate contract.
📍 Affects 2 files
kubernetes/helm/platform-api-helm-chart/templates/certificate.yaml#L24-L29(this comment)kubernetes/helm/platform-api-helm-chart/templates/issuer.yaml#L3-L4
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/platform-api-helm-chart/templates/certificate.yaml` around
lines 24 - 29, Reject incompatible createIssuer and issuerRef.kind settings in
certificate.yaml: when createIssuer is true, require issuerRef.kind to be Issuer
or force the generated Certificate reference to kind Issuer. Align the rendering
gate in kubernetes/helm/platform-api-helm-chart/templates/issuer.yaml lines 3-4
with this Certificate contract; update both sites accordingly.
| log_level = {{ $cfg.logLevel | quote }} | ||
| log_format = {{ $cfg.logFormat | quote }} | ||
| port = {{ $pa.containerPort | toString | quote }} | ||
| enable_scope_validation = {{ $cfg.enableScopeValidation }} | ||
|
|
||
| [database] | ||
| driver = {{ $db.driver | quote }} | ||
| {{- if eq $db.driver "postgres" }} | ||
| host = {{ $db.postgres.host | quote }} | ||
| port = {{ $db.postgres.port }} | ||
| name = {{ $db.postgres.database | quote }} | ||
| user = {{ $db.postgres.user | quote }} | ||
| ssl_mode = {{ $db.postgres.sslmode | quote }} | ||
| max_open_conns = {{ $db.postgres.max_open_conns }} | ||
| max_idle_conns = {{ $db.postgres.max_idle_conns }} | ||
| conn_max_lifetime = {{ $db.postgres.conn_max_lifetime }} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate configmap and values =="
fd -a 'configmap\.yaml|values\.ya?ml$' .github kubernetes .github 2>/dev/null | sed 's#^\./##' | head -80
echo
echo "== configmap excerpt =="
configmap=$(fd 'configmap\.yaml' kubernetes | head -1)
if [ -n "$configmap" ]; then
wc -l "$configmap"
cat -n "$configmap" | sed -n '1,140p'
fi
echo
echo "== values excerpts for defaults =="
for f in $(fd 'values\.ya?ml$' kubernetes); do
echo "--- $f"
rg -n "containerPort|postgres:|port:|database|logLevel|enableScopeValidation" "$f" | head -120
done
echo
echo "== search config/type definitions =="
rg -n "type .*(Config|Platform|Database)|Port int|int64|toml|toml:" -S --glob '*.go' . | head -200Repository: wso2/api-platform
Length of output: 29672
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== platform-api configmap =="
wc -l kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml
cat -n kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml | sed -n '1,100p'
echo
echo "== platform-api values relevant sections =="
cat -n kubernetes/helm/platform-api-helm-chart/values.yaml | sed -n '1,110p'
cat -n kubernetes/helm/platform-api-helm-chart/values.yaml | sed -n '210,225p'
echo
echo "== exact config.toml field assignments in platform-api helm chart templates =="
rg -n "log_level|log_format|port =|enable_scope_validation|database|driver =|host =|port =|name =|user =|ssl_mode|max_open_conns|max_idle_conns|conn_max_lifetime" kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml
echo
echo "== platform-api chart files =="
git ls-files kubernetes/helm/platform-api-helm-chartRepository: wso2/api-platform
Length of output: 13130
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== search Platform API config structs in repo =="
rg -n "type .*Config|struct|toml:|koanf:|containerPort|postgres:|port int|port .*int|type Port|database" --glob '*.go' platform docker ci gateway cmd kubernetes/common gateway 2>/dev/null | rg -i "platform|api|config|toml|containerPort|postgres|database" | head -250
echo
echo "== find likely Platform API server files from tracked files =="
git ls-files | rg 'platform-|api-platform|platform.*api|cmd/platform|main\.go|server.*go|config.*go' | head -250Repository: wso2/api-platform
Length of output: 27396
🌐 Web query:
platform-api config.platform.api.toml port database.postgres.port config-platform-api.toml
💡 Result:
In the context of the WSO2 API Platform, configurations for the Platform API are commonly managed using files named config-platform-api.toml [1][2]. While there is no single global standard for these configuration filenames across all software, the following points describe how database and port configurations are typically handled in these TOML files: 1. Database Port Configuration: When using PostgreSQL, the database port is often specified within the database configuration section of the TOML file. While the default port for PostgreSQL is 5432 [3], it may be explicitly set using a parameter such as port or through a connection string depending on the specific implementation [4][3][5]. For example, in some WSO2-related configurations, you might see settings like DP_DB_PORT=5432 or similar structures when using environment variables to override or set these values [4]. 2. Service Port Configuration: The API service itself (the platform-api) often defines its own listening port within its configuration or via container-level environment variables [1][6][5]. In the WSO2 API Platform, for instance, the platform-api service is frequently configured to run on a specific port (such as 9243) [1]. 3. Implementation Details: - Configuration files like config-platform-api.toml are used to customize settings such as user authentication and organization details [1]. - It is common to find template files (e.g., config-platform-api-template.toml) provided alongside the active configuration file, which serve as a reference for all available parameters [2]. - If you are managing these services via Docker, environment variables are frequently used to override the defaults defined in the.toml files [1][4]. To identify the exact parameter names for your specific instance, you should refer to the config-platform-api-template.toml file provided in your platform's configuration directory [2].
Citations:
- 1: https://github.com/wso2/api-platform/blob/main/portals/developer-portal/docker-compose.yaml
- 2: https://github.com/wso2/api-platform/tree/main/portals/ai-workspace
- 3: https://docs.pgdog.dev/configuration/pgdog.toml/databases/
- 4: https://github.com/wso2/api-platform/blob/main/portals/developer-portal/distribution/docker-compose.yaml
- 5: https://github.com/MODERATE-Project/moderate-platform-api/blob/main/README.md
- 6: https://mintlify.wiki/LeonardoCaero/platform-api/quickstart
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== search config-platform-api.toml references and templates =="
git ls-files | rg 'config[-_]?platform[-_]api|platform[-_]api.*toml|chart.*values|values.*chart' | head -200
echo
echo "== referenced config-platform-api fields =="
rg -n "config-platform-api|config\.platform\.api|containerPort|postgres:|port:\s*9243|port:\s*5432|database:" --glob '*.{yaml,yml,json,toml,go,md,txt}' . | head -300
echo
echo "== platform-api chart helper/deployment/service/porting =="
cat -n kubernetes/helm/platform-api-helm-chart/templates/_helpers.tpl | sed -n '1,260p'
cat -n kubernetes/helm/platform-api-helm-chart/values.yaml | sed -n '230,340p'Repository: wso2/api-platform
Length of output: 42747
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== platform-api template files =="
git ls-files platform-api | rg '(^|/)(config|internal|docker|\.go$|\.toml$)' | head -250
echo
echo "== config-template/top-level comments =="
wc -l platform-api/config/config-template.toml
cat -n platform-api/config/config-template.toml | sed -n '1,160p'
echo
echo "== Go config structs in platform-api =="
rg -n "type Config|type .*Config|Port int|Host string|Path string|DSN |postgres:|postgres|toml:|koanf:" platform-api --glob '*.go' | head -300
echo
echo "== Platform API config files references in source =="
rg -n "log_level|log_format|port|database|postgres|port: 5432|port: 9243|containerPort|config-platform-api" platform-api --glob '{*.go,*.toml,*.yaml,*.yml,*.md}' | head -350Repository: wso2/api-platform
Length of output: 50373
🌐 Web query:
github wso2 api-platform platform-api config-template.toml log_level port database
💡 Result:
In the WSO2 API Platform project, configuration is managed using TOML files, with config-template.toml serving as a reference template located in the gateway/configs/ directory of the repository [1][2][3]. The config-template.toml file organizes configurations into sections, including settings for ports, databases, and logging [1][4]. Below is an overview of how these parameters are structured: Port Configuration Ports for the gateway controller are defined under the [controller.server] section (e.g., api_port) and the [router] section (e.g., listener_port, https_port) [1][3][5]. These ports are typically integers, such as 9090 for management or 8080/8443 for traffic listeners [1][3][5]. Database Configuration Database settings are structured by component. For instance, event hub database settings are defined under [controller.event_hub.database], which includes parameters for connection pooling such as max_open_conns, max_idle_conns, conn_max_lifetime, and conn_max_idle_time [1][4]. Local storage paths for databases, such as SQLite, are configured under [controller.storage.sqlite] [1]. Log Level Logging configurations are managed within the router or controller sections, often under blocks related to access logs (e.g., [router.access_logs]) [1]. While specific log level keys may vary by version and component, they are generally defined within their respective functional blocks in the TOML file. Customization To customize your configuration, you should copy the config-template.toml to a new file named config.toml in the same directory and modify the values as needed [5]. When deploying via Helm, these configurations are often managed through values.yaml files, which the chart then renders into the final config.toml used by the gateway controller [6][5]. Top results: [1][3][5][4]
Citations:
- 1: https://github.com/wso2/api-platform/blob/main/gateway/configs/config-template.toml
- 2: https://github.com/wso2/api-platform/tree/main/gateway/configs
- 3: Proposal: Migrate Configuration Format from YAML to TOML #633
- 4: aec498a
- 5: https://wso2.com/api-platform/docs/api-gateway/setup/upstream-timeouts/
- 6: https://wso2.com/api-platform/docs/cloud/api-platform-gateway/setting-up/
Render Platform API config keys to their actual TOML shapes.
This template is writing under top-level keys (log_level, port, enable_scope_validation, [database], [auth.jwt]), but platform-api/config/config.go reads platform_api.* keys such as platform_api.port, platform_api.database.port, and platform_api.server.http.https. Both the emitted keys and the quoted service port need to match the 0.12.0 config schema, otherwise the rendered ConfigMap will fail to unmarshal at startup.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/helm/platform-api-helm-chart/templates/configmap.yaml` around
lines 18 - 33, Update the ConfigMap TOML emitted by the platform API
configuration template to use the 0.12.0 schema rooted under platform_api,
including nested database, auth.jwt, and server.http sections as expected by
config.go. Move the existing top-level keys into their corresponding
platform_api paths and ensure the service port is rendered as a numeric TOML
value rather than a quoted string. Preserve the current conditional PostgreSQL
fields while placing them under platform_api.database.
1 participant
This pull request introduces Helm packaging and release automation for several platform UI components, along with supporting chart definitions and helper templates. The main changes are the addition of GitHub Actions workflows for Helm chart releases, new chart definitions for the AI Workspace UI, and shared Helm helper templates to standardize deployment configuration.
Related to #2557 and #2560
Helm Release Automation:
ai-workspace-ui(.github/workflows/ai-workspace-ui-helm-release.yml)developer-portal-ui(.github/workflows/developer-portal-ui-helm-release.yml)platform-api(.github/workflows/platform-api-helm-release.yml)Helm Chart Definitions and Structure:
ai-workspace-ui, includingChart.yamland.helmignorefor packaging and build artifact exclusion. [1] [2].gitignorein thekubernetes/helm/directory to ignore generated chart dependencies, lockfiles, and environment-specific secrets.Shared Helm Helper Templates:
_helpers.tplfor theai-workspace-ui-helm-chart, providing reusable Helm template functions for consistent resource naming, label management, image handling, and secret reference validation across components.