Allow to use proLicense when set in secret#84
Conversation
Road to 1.0.19 🚀
Road to 1.0.20 🚀
Road to 1.0.21 🚀
|
Warning Review limit reached
More reviews will be available in 56 minutes and 11 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Walkthrough
ChangesPRO_LICENSE_KEY Secret Resolution in Scheduler Deployment
Estimated code review effort🎯 2 (Simple) | ⏱️ ~5 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@charts/bunkerweb/templates/scheduler-deployment.yaml`:
- Around line 85-93: The secretKeyRef block for the PRO_LICENSE_KEY environment
variable that references the pro-license-key from the existingSecret is missing
the optional: true field. When existingSecret is configured but does not contain
the pro-license-key, the Pod will fail to start. Add optional: true to the
secretKeyRef block (alongside name and key) to make this secret reference
optional, allowing non-PRO deployments where the license key is not required to
function properly. This follows the same pattern already used in
mcp-deployment.yaml for optional secret references.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 9b4b662e-4b05-4869-a426-373dcc362a5e
📒 Files selected for processing (1)
charts/bunkerweb/templates/scheduler-deployment.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Use the existingSecret pattern to allow users to reference pre-created Kubernetes Secrets instead of embedding credentials in values.yaml, injecting sensitive values (DB URI, Redis password, admin credentials, API keys) via secretKeyRef
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/**/*.yaml
⚙️ CodeRabbit configuration file
charts/bunkerweb/templates/**/*.yaml: These are Helm v3 Go-templated Kubernetes manifests (mixing{{- ... -}}actions with K8s YAML). Apply rules to the RENDERED Kubernetes intent, not to the Go template control blocks:
- Every component is gated by
.Values.<component>.enabled(oreq .Values.bunkerweb.kind "<Kind>"). Preserve that guard; do not render workloads unconditionally.- Pod/container
securityContextshould preferrunAsNonRoot: true,allowPrivilegeEscalation: false, dropped capabilities,seccompProfile: RuntimeDefault, and a read-only root filesystem where the component tolerates it.- Declare resource
requests/limitsand sensiblelivenessProbe/readinessProbewhere the component supports them.- Pin images to explicit tags or digests; never
:latest. Image tag should track the chartappVersionfor BunkerWeb components.- Sensitive values (database URI, Redis password, admin creds, API keys) must be injected via
secretKeyRefand honour theexistingSecretpattern — never rendered as plaintext env values.- Use
nindent/indentcorrectly so helper output stays valid YAML; do not breaktoYaml | nindentblocks.- RBAC (
clusterrole.yaml) must stay least-privilege; flag new*verbs/resources or cluster-wide grants without justification.NetworkPolicychanges must not silently widen ingress/egress beyond the components that need it.
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
🔇 Additional comments (2)
charts/bunkerweb/templates/scheduler-deployment.yaml (2)
135-135: LGTM!
85-93: Please validate chart rendering across value combinations before merge.Run
./scripts/validate-chart.shfor this YAML template change to catch Helm rendering/indentation regressions across supported configurations.As per coding guidelines, "Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations".
Source: Coding guidelines
There was a problem hiding this comment.
Pull request overview
This PR updates the BunkerWeb scheduler Helm template to allow providing the PRO license key via settings.existingSecret (using the pro-license-key secret key), instead of only via scheduler.proLicenseKey.
Changes:
- Add
valueFrom.secretKeyRefwiring forPRO_LICENSE_KEYwhensettings.existingSecretis set. - Keep existing direct value support via
scheduler.proLicenseKey.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@charts/bunkerweb/templates/scheduler-deployment.yaml`:
- Around line 85-92: The documentation in charts/bunkerweb/values.yaml for the
existingSecret configuration does not clarify that the pro-licence-key is
optional for non-PRO deployments, which contradicts the template's optional:
true setting in scheduler-deployment.yaml. Update the existingSecret
documentation in values.yaml to explicitly state that pro-licence-key is
optional and only required when using BunkerWeb PRO features, while other keys
like mariadb-password, api-token, api-username, api-password, and database-uri
remain required. This will align the documentation with the actual template
behavior and set proper user expectations.
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
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: ASSERTIVE
Plan: Pro
Run ID: 24a7a757-3e7d-4128-bfcb-ee0d5fc68b22
📒 Files selected for processing (1)
charts/bunkerweb/templates/scheduler-deployment.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Use the existingSecret pattern to allow users to reference pre-created Kubernetes Secrets instead of embedding credentials in values.yaml, injecting sensitive values (DB URI, Redis password, admin credentials, API keys) via secretKeyRef
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/**/*.yaml
⚙️ CodeRabbit configuration file
charts/bunkerweb/templates/**/*.yaml: These are Helm v3 Go-templated Kubernetes manifests (mixing{{- ... -}}actions with K8s YAML). Apply rules to the RENDERED Kubernetes intent, not to the Go template control blocks:
- Every component is gated by
.Values.<component>.enabled(oreq .Values.bunkerweb.kind "<Kind>"). Preserve that guard; do not render workloads unconditionally.- Pod/container
securityContextshould preferrunAsNonRoot: true,allowPrivilegeEscalation: false, dropped capabilities,seccompProfile: RuntimeDefault, and a read-only root filesystem where the component tolerates it.- Declare resource
requests/limitsand sensiblelivenessProbe/readinessProbewhere the component supports them.- Pin images to explicit tags or digests; never
:latest. Image tag should track the chartappVersionfor BunkerWeb components.- Sensitive values (database URI, Redis password, admin creds, API keys) must be injected via
secretKeyRefand honour theexistingSecretpattern — never rendered as plaintext env values.- Use
nindent/indentcorrectly so helper output stays valid YAML; do not breaktoYaml | nindentblocks.- RBAC (
clusterrole.yaml) must stay least-privilege; flag new*verbs/resources or cluster-wide grants without justification.NetworkPolicychanges must not silently widen ingress/egress beyond the components that need it.
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
🧠 Learnings (1)
📚 Learning: 2026-06-22T08:57:01.786Z
Learnt from: anthosz
Repo: bunkerity/bunkerweb-helm PR: 84
File: charts/bunkerweb/templates/scheduler-deployment.yaml:85-93
Timestamp: 2026-06-22T08:57:01.786Z
Learning: In the bunkerweb Helm chart, when `.Values.settings.existingSecret` is set, the documented contract in `charts/bunkerweb/values.yaml` means all referenced secret keys (e.g., `pro-license-key`, `database-uri`, etc.) are mandatory. Therefore, any `secretKeyRef` entries in chart templates that read these keys (such as `charts/bunkerweb/templates/scheduler-deployment.yaml`) must not use `optional: true`; they should fail fast if the key is missing.
Applied to files:
charts/bunkerweb/templates/scheduler-deployment.yaml
🔇 Additional comments (1)
charts/bunkerweb/templates/scheduler-deployment.yaml (1)
137-137: LGTM!
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. ❌ Cannot run autofix: This PR has merge conflicts. Please resolve the conflicts with the base branch and try again. Alternatively, use |
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. An unexpected error occurred while generating fixes: Connect Timeout Error (attempted address: api.github.com:443, timeout: 10000ms) |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
charts/bunkerweb/templates/scheduler-deployment.yaml (1)
96-99: 🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy liftDo not render
PRO_LICENSE_KEYas plaintext.Line 98 injects a sensitive key via
value, which exposes it in rendered manifests/release metadata. Keep this env var secret-backed only (existingSecret or a chart-managed Secret).As per path instructions, "Sensitive values (database URI, Redis password, admin creds, API keys) must be injected via
secretKeyRefand honour theexistingSecretpattern — never rendered as plaintext env values."🤖 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 `@charts/bunkerweb/templates/scheduler-deployment.yaml` around lines 96 - 99, The scheduler deployment template is rendering `PRO_LICENSE_KEY` directly as plaintext through the `value` field, which should be avoided. Update the `scheduler-deployment.yaml` env block to source `PRO_LICENSE_KEY` from a secret via `secretKeyRef`, following the same `existingSecret`/chart-managed Secret pattern used for other sensitive settings. Keep the conditional logic around `.Values.scheduler.proLicenseKey`, but replace the direct value injection with a secret-backed reference in the scheduler container spec.Source: Path instructions
🤖 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.
Outside diff comments:
In `@charts/bunkerweb/templates/scheduler-deployment.yaml`:
- Around line 96-99: The scheduler deployment template is rendering
`PRO_LICENSE_KEY` directly as plaintext through the `value` field, which should
be avoided. Update the `scheduler-deployment.yaml` env block to source
`PRO_LICENSE_KEY` from a secret via `secretKeyRef`, following the same
`existingSecret`/chart-managed Secret pattern used for other sensitive settings.
Keep the conditional logic around `.Values.scheduler.proLicenseKey`, but replace
the direct value injection with a secret-backed reference in the scheduler
container spec.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b7a9ee79-a3bb-4e7f-b5b2-2b7940a924d1
📒 Files selected for processing (1)
charts/bunkerweb/templates/scheduler-deployment.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Use the existingSecret pattern to allow users to reference pre-created Kubernetes Secrets instead of embedding credentials in values.yaml, injecting sensitive values (DB URI, Redis password, admin credentials, API keys) via secretKeyRef
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
charts/bunkerweb/templates/**/*.yaml
⚙️ CodeRabbit configuration file
charts/bunkerweb/templates/**/*.yaml: These are Helm v3 Go-templated Kubernetes manifests (mixing{{- ... -}}actions with K8s YAML). Apply rules to the RENDERED Kubernetes intent, not to the Go template control blocks:
- Every component is gated by
.Values.<component>.enabled(oreq .Values.bunkerweb.kind "<Kind>"). Preserve that guard; do not render workloads unconditionally.- Pod/container
securityContextshould preferrunAsNonRoot: true,allowPrivilegeEscalation: false, dropped capabilities,seccompProfile: RuntimeDefault, and a read-only root filesystem where the component tolerates it.- Declare resource
requests/limitsand sensiblelivenessProbe/readinessProbewhere the component supports them.- Pin images to explicit tags or digests; never
:latest. Image tag should track the chartappVersionfor BunkerWeb components.- Sensitive values (database URI, Redis password, admin creds, API keys) must be injected via
secretKeyRefand honour theexistingSecretpattern — never rendered as plaintext env values.- Use
nindent/indentcorrectly so helper output stays valid YAML; do not breaktoYaml | nindentblocks.- RBAC (
clusterrole.yaml) must stay least-privilege; flag new*verbs/resources or cluster-wide grants without justification.NetworkPolicychanges must not silently widen ingress/egress beyond the components that need it.
Files:
charts/bunkerweb/templates/scheduler-deployment.yaml
🧠 Learnings (1)
📚 Learning: 2026-06-22T08:57:01.786Z
Learnt from: anthosz
Repo: bunkerity/bunkerweb-helm PR: 84
File: charts/bunkerweb/templates/scheduler-deployment.yaml:85-93
Timestamp: 2026-06-22T08:57:01.786Z
Learning: In the bunkerweb Helm chart, when `.Values.settings.existingSecret` is set, the documented contract in `charts/bunkerweb/values.yaml` means all referenced secret keys (e.g., `pro-license-key`, `database-uri`, etc.) are mandatory. Therefore, any `secretKeyRef` entries in chart templates that read these keys (such as `charts/bunkerweb/templates/scheduler-deployment.yaml`) must not use `optional: true`; they should fail fast if the key is missing.
Applied to files:
charts/bunkerweb/templates/scheduler-deployment.yaml
🔇 Additional comments (3)
charts/bunkerweb/templates/scheduler-deployment.yaml (3)
89-96:optional: trueonpro-license-keyconflicts with the documented secret contract (already raised).Line 95 makes
pro-license-keyoptional even whensettings.existingSecretis set.Based on learnings, when
.Values.settings.existingSecretis configured, referenced keys likepro-license-keyare mandatory and should fail fast if missing.Source: Learnings
26-29: LGTM!Also applies to: 111-114, 146-149
89-99: 📐 Maintainability & Code QualityRun chart validation for this YAML template change.
Please run
./scripts/validate-chart.shand attach the output.As per coding guidelines, "
**/*.yaml: Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations".Source: Coding guidelines
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@charts/bunkerweb/values.yaml`:
- Line 61: The comment in values.yaml uses the misspelled secret key name and
should match the public-facing key used by the scheduler template and generated
docs. Update the comment near the pro license key setting to use the exact
symbol pro-license-key consistently so users know the correct secret name to
provide. Keep the wording aligned with the chart’s configuration schema and any
references in the scheduler template/docs.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: b3fe166e-db60-413b-a3cf-599e3a5d76fc
📒 Files selected for processing (1)
charts/bunkerweb/values.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Always run ./scripts/validate-chart.sh before committing to test template rendering across many configuration combinations
Files:
charts/bunkerweb/values.yaml
charts/bunkerweb/*.yaml
📄 CodeRabbit inference engine (CLAUDE.md)
Use conditional rendering with .Values..enabled to gate component deployment (Scheduler, Controller, UI, API, MariaDB, Redis, Prometheus, Grafana)
Files:
charts/bunkerweb/values.yaml
charts/bunkerweb/values.yaml
⚙️ CodeRabbit configuration file
charts/bunkerweb/values.yaml:values.yamlis the chart's public configuration schema and the source for generated docs:
- Keep key paths and naming consistent with the existing structure (
settings,service,bunkerweb,scheduler,controller,ui,api,mariadb,redis,prometheus,grafana,ingressClass,gatewayClass,networkPolicy).- Defaults must be production-safe: keep the shipped defaults (notably
api.enabled: falseandnetworkPolicy.enabled: false) unless a change is justified. Notecontroller.enabledandui.enabledship astrueby default — preserve that posture rather than assuming components are off. Do not flip secure defaults without justification.- Secrets must default to empty and support the
existingSecretpattern rather than carrying real credentials.- Every new key needs a short explanatory comment; when a new BunkerWeb feature is added under
scheduler.features, update thebunkerweb.featureEnvshelper AND regeneratedocs/values.mdviapython3 scripts/generate-docs.pyin the same PR.- Image repository/tag fields should not default to
latest.
Files:
charts/bunkerweb/values.yaml
When proLicense is set in secret, it's not take into account, here is a fix