Update kubeapps v2.12.0 #533
Conversation
Signed-off-by: Andrei Kvapil <[email protected]>
dosubot
bot
added
the
size:L
WalkthroughThis pull request introduces comprehensive updates across multiple configuration files and Dockerfiles for the Kubeapps dashboard and APIs. The changes primarily focus on version upgrades, API migrations from beta to stable versions, and enhanced configuration management. Key modifications include updating Dockerfiles to newer versions, refactoring FluxCD integrations to use v1 APIs, adding conditional OIDC configurations, and introducing new labeling strategies for Helm releases and repositories. Changes
Sequence DiagramsequenceDiagram
participant Config as Configuration Management
participant OIDC as OIDC Service
participant Dashboard as Kubeapps Dashboard
participant Keycloak as Keycloak Operator
Config->>OIDC: Check oidcEnabled
alt OIDC Enabled
OIDC-->>Keycloak: Configure Keycloak
Keycloak-->>Dashboard: Provide Authentication
else OIDC Disabled
Dashboard->>Dashboard: Use Default Auth
end
Possibly Related PRs
Suggested Labels
Suggested Reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (2)
packages/system/dashboard/images/kubeapps-apis/dashboard-resource.diff (1)
Line range hint
462-467: Confirm that each discovered resource has a stable or known API version.
You rely on “mapper.KindFor(gvr)” to convert resource references. Watch out for alpha or beta resources that may not have the “v1” version, as you currently hardcode the “Version: ‘v1’” in GroupVersionResource. If upstream resources or custom CRDs do not adhere to v1, logic might break.packages/system/dashboard/images/dashboard/Dockerfile (1)
Line range hint
12-20: Consider using environment variables for branding customizationThe hardcoded
sedreplacements for branding customization make maintenance challenging. Consider using environment variables or build arguments for better maintainability.-RUN sed -i 's/"Kubeapps",/"Cozystack",/' lang/en.json -RUN sed -i 's/Kubeapps/Cozystack/g' public/site.webmanifest -RUN sed -i 's/Welcome To Kubeapps/Welcome To Cozystack/g' ./src/components/LoginForm/LoginForm.tsx ./src/components/AppList/AppListGrid.tsx ./src/components/AppList/AppList.test.tsx +ARG BRAND_NAME=Cozystack +RUN sed -i "s/\"Kubeapps\",/\"${BRAND_NAME}\",/" lang/en.json +RUN sed -i "s/Kubeapps/${BRAND_NAME}/g" public/site.webmanifest +RUN sed -i "s/Welcome To Kubeapps/Welcome To ${BRAND_NAME}/g" ./src/components/LoginForm/LoginForm.tsx ./src/components/AppList/AppListGrid.tsx ./src/components/AppList/AppList.test.tsx
🧹 Nitpick comments (12)
packages/system/dashboard/images/kubeapps-apis/reconcile-strategy.diff (1)
5-5: LGTM! Explicit reconciliation strategy improves release management.Setting
ReconcileStrategy: "Revision"ensures that Helm releases are reconciled based on chart revision changes, which is the recommended approach for deterministic deployments.This strategy ensures that releases are only reconciled when the chart version or values change, preventing unnecessary reconciliations and providing better control over the deployment process.
packages/system/dashboard/images/kubeapps-apis/labels.diff (2)
Line range hint
508-513: Consider documenting the labeling strategy.The consistent labeling approach across HelmReleases and HelmRepositories is good. Consider documenting this labeling strategy in the project documentation to ensure consistent usage by other developers.
Would you like me to help create documentation for the labeling strategy?
Also applies to: 927-929
Line range hint
64-65: LGTM! Consistent label filtering for repositories.The implementation maintains consistency with the HelmRelease filtering approach, ensuring a unified resource management strategy.
This consistent labeling approach will help in:
- Clear separation of UI-managed vs. externally managed resources
- Easier resource cleanup and management
- Better visibility of resources in the Kubeapps dashboard
packages/system/dashboard/values.yaml (1)
36-37: Avoid using 'latest' tag in production environmentsWhile the specific digests provide immutability, using the 'latest' tag is generally discouraged in production as it:
- Makes deployments unpredictable
- Complicates rollback procedures
- Can lead to different environments running different versions
Consider using explicit version tags (e.g.,
v2.12.0) while keeping the digests for immutability.Also applies to: 42-43
packages/system/dashboard/images/kubeapps-apis/dashboard-resource.diff (3)
2-2: Consider updating your import grouping.
You've added "encoding/json" on line 2, which is fine. However, please ensure your import blocks are consistently organized for readability—group together standard library imports before external imports.
Line range hint
462-467: Refactor repeated error logging patterns.
You are logging errors and returning them in multiple consecutive statements. A best practice is to unify logs and returns to reduce duplication and confusion.+// Example snippet merging log and return: +if err != nil { + msg := fmt.Sprintf("Failed to create discovery client: %v", err) + log.Error(msg) + return nil, connect.NewError(connect.CodeInternal, fmt.Errorf(msg)) +}
Line range hint
462-467: Improve or remove the all-or-nothing failure for missing rules.
Your code treats the absence of rules in the Role as a critical error. In some scenarios, not having any rules might be expected. Consider returning an empty ResourceRefs list instead of a system-wide error, or provide more context in the error as to why no rules are found.packages/system/dashboard/images/kubeapps-apis/fluxcd.diff (2)
Line range hint
512-512: Avoid partial spec resets when updating CRD status.The code zeros out the entire HelmRelease Status before updating. If you rely on partial state from the old status, you may lose that. Make sure clearing that status is indeed the intended behavior.
Line range hint
576-581: newFluxHelmRelease labels & reconciliation.Consider adding or extending labels to the newly created HelmRelease for better identification, e.g., “app.kubernetes.io/managed-by: kubeapps” or relevant user-defined labels. Also, verify the reconciliation strategy is correct for your use case.
packages/core/platform/bundles/paas-hosted.yaml (1)
Line range hint
143-155: Fix indentation for better readabilityThe indentation in this block is inconsistent. Consider adjusting it to match the file's style:
{{- if .Capabilities.APIVersions.Has "source.toolkit.fluxcd.io/v1" }} {{- with (lookup "source.toolkit.fluxcd.io/v1" "HelmRepository" "cozy-public" "").items }} kubeapps: redis: master: podAnnotations: {{- range $index, $repo := . }} {{- with (($repo.status).artifact).revision }} repository.cozystack.io/{{ $repo.metadata.name }}: {{ quote . }} {{- end }} {{- end }} {{- end }} {{- end }}🧰 Tools
🪛 yamllint (1.35.1)
[warning] 144-144: wrong indentation: expected 2 but found 4
(indentation)
[warning] 145-145: wrong indentation: expected 2 but found 4
(indentation)
packages/system/dashboard/images/dashboard/Dockerfile (2)
Line range hint
26-41: Optimize color scheme modificationsThe current approach of searching and replacing color codes individually is verbose and error-prone.
-RUN sed -i \ - -e 's/#2d4048/#202124/g' \ - -e 's/#25333d/#1e2023/g' \ - -e 's/#fcfdfd/#f3f4f5/g' \ - -e 's/#f1f6f8/#e7e9eb/g' \ - -e 's/#e3eaed/#d3d6da/g' \ - -e 's/#cbd4d8/#b7bbc1/g' \ - -e 's/#aeb8bc/#989da3/g' \ - -e 's/#859399/#7b7f85/g' \ - -e 's/#6a7a81/#5b686e/g' \ - -e 's/#4f6169/#4f5256/g' \ - -e 's/#3a4d55/#3a3d41/g' \ - -e 's/#2d4048/#202124/g' \ - -e 's/#21333b/#383d44/g' \ - -e 's/#1b2b32/#2a2d2f/g' \ +COPY color-map.txt /tmp/ +RUN while IFS=, read -r old_color new_color; do \ + find . -type f -exec sed -i "s/${old_color}/${new_color}/g" {} +; \ +done < /tmp/color-map.txtCreate a
color-map.txtfile:#2d4048,#202124 #25333d,#1e2023 #fcfdfd,#f3f4f5 ...
Line range hint
43-44: Consider using a specific digest for the base imageUsing a specific digest for the Nginx base image would provide better reproducibility and security.
-FROM bitnami/nginx:1.25.2 +FROM bitnami/nginx:1.25.2@sha256:1234567890abcdef... # Replace with actual digest
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
packages/core/platform/bundles/paas-full.yaml(1 hunks)packages/core/platform/bundles/paas-hosted.yaml(2 hunks)packages/system/dashboard/images/dashboard/Dockerfile(1 hunks)packages/system/dashboard/images/kubeapps-apis/Dockerfile(2 hunks)packages/system/dashboard/images/kubeapps-apis/dashboard-resource.diff(2 hunks)packages/system/dashboard/images/kubeapps-apis/fluxcd.diff(7 hunks)packages/system/dashboard/images/kubeapps-apis/labels.diff(3 hunks)packages/system/dashboard/images/kubeapps-apis/reconcile-strategy.diff(1 hunks)packages/system/dashboard/values.yaml(1 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
packages/core/platform/bundles/paas-hosted.yaml
[warning] 144-144: wrong indentation: expected 2 but found 4
(indentation)
packages/core/platform/bundles/paas-full.yaml
[warning] 215-215: wrong indentation: expected 2 but found 4
(indentation)
[warning] 216-216: wrong indentation: expected 2 but found 4
(indentation)
[warning] 220-220: wrong indentation: expected 8 but found 10
(indentation)
[warning] 221-221: wrong indentation: expected 8 but found 10
(indentation)
🪛 Gitleaks (8.21.2)
packages/system/dashboard/images/kubeapps-apis/fluxcd.diff
3015-3015: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (21)
packages/system/dashboard/images/kubeapps-apis/labels.diff (1)
Line range hint 54-56: LGTM! Well-structured label filtering implementation.
The label selector implementation for HelmReleases effectively filters UI-managed resources, improving resource management and visibility.
Let's verify the impact on existing resources:
✅ Verification successful
The label selector implementation is consistent with existing patterns
The search results show that:
- The
cozystack.io/ui: "true"label is already in use across multiple HelmReleases in the tenant and platform templates - The label is consistently applied to UI-managed resources
- The implementation follows existing patterns in the codebase, particularly in tenant and platform components
The change is safe and aligns with the existing labeling strategy in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing HelmReleases without the new label
ast-grep --pattern 'kind: HelmRelease
spec:
$$$'
Length of output: 52
Script:
#!/bin/bash
# Search for HelmRelease manifests and their labels using ripgrep
rg -U "kind:\s*HelmRelease" -A 10
# Also check for any existing label usage with cozystack.io
rg "cozystack.io/ui"
# Look for any helm-related label selectors
rg "LabelSelector.*helm" -A 2
Length of output: 21094
packages/system/dashboard/values.yaml (1)
37-37: Verify image digests correspond to Kubeapps v2.12.0
Let's ensure these digests correspond to the intended Kubeapps v2.12.0 release.
Also applies to: 43-43
packages/system/dashboard/images/kubeapps-apis/dashboard-resource.diff (3)
14-15: Validate the removal of deprecated beta imports and confirm all references are updated.
The switch to stable APIs from deprecated beta imports is good. Ensure that all references, usage patterns, and data structures previously relying on the older beta versions are fully replaced with the stable imports.
Line range hint 462-467: Validate that the newly created Role name is correct.
This code constructs a role name as “<pkgRef.Identifier>-dashboard-resources” when making a GVR call. Confirm that the dynamically constructed name is correct, and consider gracefully handling naming collisions by either generating unique suffixes or verifying the role’s presence in a more flexible manner.
Line range hint 462-467: Ensure backward compatibility with existing release logic.
The call to “getReleaseInCluster” and references to “hrName” have been replaced by a more dynamic approach using the custom role. Verify that existing references to the old logic in other parts of the codebase are either removed or refactored.
✅ Verification successful
Let me gather more information about the changes and their impact.
Based on the search results, I can now generate the final response:
Migration from helmv2beta2 to helmv2 appears to be a coordinated change
The changes to getReleaseInCluster and hrName are part of a broader, systematic migration from helmv2beta2 to helmv2 across the codebase. All references have been consistently updated:
- Type definitions changed from
helmv2beta2.HelmReleasetohelmv2.HelmRelease - Function signatures and struct fields updated accordingly
- Related types like
HelmReleaseSpec,HelmChartTemplate, etc. also migrated - No stray references to the old
helmv2beta2package remain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Confirm no leftover references to "getReleaseInCluster" or "hrName" remain
rg -A 5 'getReleaseInCluster|hrName'
Length of output: 2417
Script:
#!/bin/bash
# Search for any remaining references to helmReleaseName function
ast-grep --pattern 'helmReleaseName($$$)'
# Search for any other files that might be importing or using HelmRelease type
rg -A 3 'helmv2(beta2)?\.HelmRelease'
Length of output: 46549
packages/system/dashboard/images/kubeapps-apis/fluxcd.diff (9)
2-2: Migration from v1beta2 to v1 references.
Good to see that the comment has been updated to reflect the new v1 API references. This change helps maintain consistency after switching to the stable API.
Line range hint 131-131: Ensure NewObjFunc, NewListFunc usage is consistent.
The docstring comment clarifies you are now dealing with “sourcev1.HelmRepository, in a generic fashion”. Make sure any watchers or orchestrator logic using these objects is also updated to the new stable API objects.
Line range hint 187-187: Test coverage for new HelmChart references.
Switching from “sourcev1beta2.HelmChart” to “sourcev1.HelmChart” is essential, but be sure to extend your test coverage for new stability or potential changes in the HelmChart CRD.
Line range hint 979-1003: Validate relative URL logic with new v1 types.
The relative URL logic is still referencing the newly replaced v1 structures. Double-check that the “Artifact” and “digest” field usage matches the updated schema fields in v1.
Line range hint 131-131: Confirm RBAC coverage for HelmRepository + HelmChart.
The lines updating policy rules from beta to stable group versions look accurate. Ensure that the ServiceAccount, Role, and RoleBinding references are in sync, especially for ephemeral or test namespaces.
Also applies to: 329-329
Line range hint 236-236: Check status fields for “LastAttemptedRevision”.
You replaced usage of “LastAppliedRevision” with “LastAttemptedRevision.” Validate that flux v1 sets “LastAttemptedRevision” in all relevant success/failure transitions so the displayed package versions remain accurate for the UI.
2830-2848: Dependency updates in go.mod.
Upgrading to the new fluxcd modules (helm-controller/api v1.1.0 and source-controller/api v1.4.1) is a positive move. After updating, confirm the new modules are stable in your environment and do not introduce backward compatibility issues for older cluster versions.
2964-2964: Check pinned versions for security patches.
The updated dependencies (e.g., “requests”, “prometheus”, etc.) appear well-curated, but ensure that pinned versions (like “k8s.io” modules) have no known security advisories.
Line range hint 12-27: Check for any lingering references to v1beta2.
Although these lines correctly replace “sourcev1beta2” with “sourcev1”, please ensure all function calls elsewhere are also updated to avoid runtime type mismatch.
✅ Verification successful
Based on the ripgrep results, I can see that all references to sourcev1beta2 have been systematically replaced with sourcev1 throughout the codebase, including:
- Import statements
- Type references
- Group/Version/Kind references
- Constants and enum values
- Function signatures and struct definitions
The changes appear to be comprehensive and consistent, with no lingering references to v1beta2. Let me verify this with one more search to be absolutely certain:
All references to v1beta2 have been properly updated to v1
The comprehensive review of the changes shows that all references to sourcev1beta2 have been systematically and consistently replaced with sourcev1 across the entire codebase, including imports, types, constants, and function signatures. The follow-up verification search returned no results, confirming no lingering v1beta2 references remain.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for any leftover references to "sourcev1beta2" across the codebase
rg -A 3 "sourcev1beta2"
Length of output: 65560
Script:
#!/bin/bash
# Double check for any remaining v1beta2 references that might have been missed
rg "v1beta2" --type-add 'go:*.{go,mod}' --type go
Length of output: 49
packages/core/platform/bundles/paas-hosted.yaml (1)
157-161: Consider adding error handling for malformed YAML
While the ConfigMap lookup and value extraction is correct, consider adding error handling for malformed YAML in the ConfigMap.
packages/system/dashboard/images/kubeapps-apis/Dockerfile (2)
20-20: Review Go version upgrade carefully
The upgrade from Go 1.22.5 to 1.23.4 is a major version change. This could introduce compatibility issues or behavioral changes.
Consider:
- Testing the build thoroughly
- Reviewing the Go 1.23 release notes for breaking changes
- Ensuring all dependencies are compatible with Go 1.23
✅ Verification successful
Go version upgrade appears compatible with project dependencies
The project's go.mod file already declares Go 1.23.0 as its version, and all dependencies are recent versions that are typically compatible with Go 1.23. The upgrade from 1.22.5 to 1.23.4 in the Dockerfile is a patch version update within the same major version (1.23.x) that's already in use by the project.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the project's dependencies are compatible with Go 1.23
rg -l 'go 1\.' | while read -r file; do
echo "Checking $file:"
cat "$file"
done
Length of output: 5375
7-7: Verify Kubeapps v2.12.0 stability
The version update aligns with the PR objective. Let's verify the stability of this version.
✅ Verification successful
Version v2.12.0 is stable and suitable for use
The version update is safe as evidenced by:
- Official release notes confirm v2.12.0 is a stable minor release (chart version 17.0.2)
- Changes primarily consist of dependency upgrades and minor improvements
- No critical issues or bugs reported against this version
- Clear installation instructions and documentation provided
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check release notes and any reported issues for v2.12.0
gh api repos/vmware-tanzu/kubeapps/releases/tags/v2.12.0 --jq '.body' || echo "Release not found"
gh api repos/vmware-tanzu/kubeapps/issues --jq '.[] | select(.title | contains("2.12.0")) | {title: .title, state: .state}'
Length of output: 6853
packages/core/platform/bundles/paas-full.yaml (2)
214-225: Same indentation issue as in paas-hosted.yaml
The indentation inconsistency is present here as well.
🧰 Tools
🪛 yamllint (1.35.1)
[warning] 215-215: wrong indentation: expected 2 but found 4
(indentation)
[warning] 216-216: wrong indentation: expected 2 but found 4
(indentation)
[warning] 220-220: wrong indentation: expected 8 but found 10
(indentation)
[warning] 221-221: wrong indentation: expected 8 but found 10
(indentation)
227-231: Same ConfigMap handling as in paas-hosted.yaml
The ConfigMap lookup and value extraction implementation is identical.
packages/system/dashboard/images/dashboard/Dockerfile (2)
Line range hint 22-24: LGTM: Build process follows best practices
The build process correctly uses:
- Frozen lockfile for deterministic builds
- Code quality checks before building
- Proper build command sequence
7-8: Verify the compatibility of the new version
The version upgrade from 2.11.0 to 2.12.0 needs verification to ensure compatibility with the existing setup.
✅ Verification successful
Based on the changelog output, I can generate the final response:
Version 2.12.0 is compatible with existing setup
The upgrade from 2.11.0 to 2.12.0 primarily includes dependency updates and minor UI style changes. Key points from the changelog:
- No breaking changes reported
- Mainly includes dependency upgrades and minor bug fixes
- UI changes are limited to style updates from dependency bumps
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for breaking changes in the changelog between v2.11.0 and v2.12.0
gh api repos/vmware-tanzu/kubeapps/releases | jq -r '.[] | select(.tag_name | test("v2.1[1-2].0")) | .body'
# Check if the downloaded archive structure matches expected paths
wget -qO- https://github.com/vmware-tanzu/kubeapps/archive/refs/tags/v2.12.0.tar.gz | tar tzf - | grep -E "^kubeapps-2.12.0/dashboard/"
Length of output: 20193
| +github.com/fluxcd/source-controller/api v1.3.0/go.mod h1:+tfd0vltjcVs/bbnq9AlYR9AAHSVfM/Z4v4TpQmdJf4= | ||
| -github.com/fluxcd/source-controller/api v1.2.5 h1:MgGrOfPh7Grhl40GUM9lEs+lmgTx3hLAwI0MVqaJkQ8= | ||
| -github.com/fluxcd/source-controller/api v1.2.5/go.mod h1:j3QSHpIPBP5sjaGIkVtsgWCx8JcOmcsutRmdJmRMOZg= | ||
| +github.com/fluxcd/source-controller/api v1.4.1 h1:zV01D7xzHOXWbYXr36lXHWWYS7POARsjLt61Nbh3kVY= |
There was a problem hiding this comment.
Potential secret exposure detected by Gitleaks.
Static analysis flags a possible generic API key. Examine whether this is truly a secret or false positive. If legitimate, remove or relocate it to a more secure channel (e.g., environment variables, Vault, or a sealed secret).
🧰 Tools
🪛 Gitleaks (8.21.2)
3015-3015: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Signed-off-by: Andrei Kvapil [email protected]
upstream issue vmware-tanzu/kubeapps#7847
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
values.yamlfor image tags and digests.Chores