-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add values and checks #454
Conversation
WalkthroughThe pull request introduces several modifications across multiple scripts and configuration files. Key changes include the enhancement of the Changes
Possibly related PRs
Suggested labels
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (3)
hack/testdata/nats/values.yaml (1)
4-7
: Enhance parameter documentation with security and operational detailsConsider adding more detailed documentation for each parameter:
external
: Include security implications and required network configurationsreplicas
: Add recommended ranges and high availability considerationsstorageClass
: Mention implications of empty value and recommended storage classes## @param external Enable external access from outside the cluster +## Note: Enabling external access requires proper security configurations and may expose +## the NATS cluster to external traffic. Ensure appropriate network policies are in place. +## ## @param replicas Number of NATS instances to run in the cluster +## Recommended range: 1-5. For production environments, minimum of 3 replicas +## is recommended for high availability. +## ## @param storageClass StorageClass used to store the data +## If empty, the cluster's default storage class will be used. +## Ensure the chosen storage class supports the required performance characteristics.hack/testdata/kubernetes/values.yaml (1)
4-4
: Fix typo in documentation commentThere's a typo in the parameter description: "contorl-plane" should be "control-plane"
-## @param controlPlane.replicas Number of replicas for Kubernetes contorl-plane components +## @param controlPlane.replicas Number of replicas for Kubernetes control-plane componentshack/e2e.application.sh (1)
12-13
: Parameterize base paths for better flexibility.Hardcoding
values_base_path
andchecks_base_path
may limit the script's flexibility. Consider making these paths configurable through command-line arguments or environment variables.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (8)
- hack/e2e.application.sh (5 hunks)
- hack/testdata/kubernetes/check.sh (1 hunks)
- hack/testdata/kubernetes/values.yaml (1 hunks)
- hack/testdata/nats/check.sh (1 hunks)
- hack/testdata/nats/values.yaml (1 hunks)
- hack/testdata/tenant/check.sh (1 hunks)
- packages/core/testing/Makefile (0 hunks)
- packages/core/testing/values.yaml (1 hunks)
💤 Files with no reviewable changes (1)
- packages/core/testing/Makefile
✅ Files skipped from review due to trivial changes (1)
- packages/core/testing/values.yaml
🧰 Additional context used
🪛 Shellcheck
hack/testdata/kubernetes/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
hack/testdata/nats/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
hack/testdata/tenant/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
🔇 Additional comments (7)
hack/testdata/nats/values.yaml (1)
8-10
: LGTM! Default values are reasonableThe default values are sensible for a basic deployment:
external: false
- Secure default that prevents unintended exposurereplicas: 2
- Provides basic redundancystorageClass: ""
- Allows flexibility by using cluster defaultshack/testdata/kubernetes/values.yaml (5)
8-10
: Consider adding validation constraints for control plane replicasThe control plane replicas are set to 2, but there's no indication of minimum/maximum values. For high availability, typically an odd number (1, 3, 5) of replicas is recommended to maintain quorum.
Consider:
- Setting an odd number for replicas (e.g., 3) for proper quorum
- Adding documentation about the recommended values and their implications
15-21
: Review node group configuration for production readinessSeveral considerations for the node group configuration:
- The minimum replicas of 0 might affect service availability
- Consider adding additional roles for better node utilization
- Validate if the instance type "u1.medium" is sufficient for the ingress-nginx workload
33-38
: Provide default cert-manager configurationWhile cert-manager is enabled, there's no default configuration provided. This might lead to misconfiguration in production.
Consider adding:
- Default issuer configuration
- Default certificate duration and renewal settings
- Documentation for required cluster-wide permissions
41-53
: Review ingress-nginx configuration for securityThe ingress-nginx configuration needs additional security considerations:
- No default SSL/TLS configuration
- Empty hosts list might allow unintended external access
- No rate limiting or security policies defined
Consider adding:
- Default SSL/TLS configuration
- Basic rate limiting rules
- Example host entries in comments for better guidance
57-62
: Define secure defaults for FluxCDFluxCD is enabled by default but lacks secure configuration defaults. Consider security implications of automated deployments.
Recommendations:
- Add default source restrictions
- Configure default reconciliation intervals
- Add documentation about required RBAC permissions
hack/e2e.application.sh (1)
159-161
: Verify the necessity of reinstalling the tenant and its impact on tests.The script reinstalls the tenant with
install_tenant
and immediately checks its status. Ensure that reinstalling the tenant does not interfere with the tests for$chart_name
, especially if they depend on the tenant's state.
## @section Common parameters | ||
|
||
## @param external Enable external access from outside the cluster | ||
## @param replicas Persistent Volume size for NATS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix incorrect parameter description for replicas
The description "Persistent Volume size for NATS" does not match the parameter's purpose. The replicas
parameter determines the number of NATS instances to run, not the volume size.
-## @param replicas Persistent Volume size for NATS
+## @param replicas Number of NATS instances to run in the cluster
📝 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.
## @param replicas Persistent Volume size for NATS | |
## @param replicas Number of NATS instances to run in the cluster |
## @param storageClass StorageClass used to store the data | ||
## | ||
external: false | ||
replicas: 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
🛠️ Refactor suggestion
Based on the analysis of the schema files across the repository, I can now provide the final response:
Add minimum and maximum constraints for replicas in schema validation
Looking at the repository's patterns, while many applications define replica counts in their schema, none currently implement minimum/maximum constraints. However, for NATS, which is a critical messaging system, adding these constraints would be beneficial:
- The current schema in
packages/apps/nats/values.schema.json
only defines type and default:
"replicas": {
"type": "number",
"description": "Persistent Volume size for NATS",
"default": 2
}
- Update it to include constraints:
"replicas": {
"type": "integer",
"description": "Number of NATS replicas",
"minimum": 1,
"maximum": 5,
"default": 2
}
Also note that the current description "Persistent Volume size for NATS" is incorrect and should be updated to "Number of NATS replicas" to match the convention used in other charts.
🔗 Analysis chain
Consider adding validation for replicas count
The replicas
value should have a minimum of 1 and a reasonable maximum limit to prevent resource exhaustion. Consider using Helm's built-in validation capabilities.
Add schema validation in the values.yaml:
replicas:
type: integer
minimum: 1
maximum: 5
default: 2
Let me check the content of the found file to understand how replica constraints are implemented in this repository.
Let me check if there are any schema validations in the NATS chart or similar Helm charts in the repository.
Let me check the schema validation for replicas in the NATS chart to see how it's implemented there.
Let me fix the regex and check for replica validation patterns in other schemas.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other NATS deployments in the repo have replica constraints
rg -l "replicas.*minimum|maximum.*replicas" --type yaml
Length of output: 131
Script:
#!/bin/bash
# Check the content of the found file focusing on replica validation
rg -A 5 -B 5 "replicas.*minimum|maximum.*replicas" packages/system/etcd-operator/charts/etcd-operator/crds/etcd-cluster.yaml
Length of output: 729
Script:
#!/bin/bash
# Search for schema validation patterns in Helm charts
rg -g 'values.schema.json' -l .
# Also check for any validation in NATS related files
fd -e yaml -e json . hack/testdata/nats/ --exec cat {}
Length of output: 1870
Script:
#!/bin/bash
# Check the content of NATS schema validation
cat packages/apps/nats/values.schema.json
# Also check if there are any other examples of replica validation in other schemas
rg -A 5 -B 5 '"replicas":\s*{' packages/apps/**/values.schema.json
Length of output: 1400
Script:
#!/bin/bash
# Check for replica validation patterns in other schema files with fixed regex
rg -A 5 -B 5 '"replicas": \{' packages/apps/**/values.schema.json
# Also check for minimum/maximum constraints in other schema files
rg -A 2 -B 2 '"minimum": |"maximum": ' packages/apps/**/values.schema.json
Length of output: 12402
resources: | ||
cpu: "" | ||
memory: "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify default resource limits
Empty resource quotas could lead to unbounded resource consumption. Consider setting default values based on your workload requirements.
resources:
- cpu: ""
- memory: ""
+ cpu: "1000m"
+ memory: "2Gi"
📝 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.
resources: | |
cpu: "" | |
memory: "" | |
resources: | |
cpu: "1000m" | |
memory: "2Gi" |
if [[ -n "$values_file" && -f "$values_file" ]]; then | ||
local values_section | ||
values_section=$(echo " values:" && sed 's/^/ /' "$values_file") | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ensure correct YAML indentation when constructing values_section
.
The current method of constructing values_section
by prepending spaces using sed 's/^/ /'
may not handle existing indentation or complex structures in the values_file
, potentially leading to invalid YAML formatting.
Consider using a YAML-aware tool like yq
to merge the values file into the HelmRelease manifest to ensure proper YAML formatting.
if [[ "$status_output" == "InstallSucceeded" || "$status_output" == "UpgradeSucceeded" ]]; then | ||
echo -e "${GREEN}Helm release '$release_name' is ready.${RESET}" | ||
make_extra_checks "$checks_file" | ||
delete_hr $release_name $namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid immediate deletion of HelmRelease after it becomes ready.
Deleting the HelmRelease immediately after it reaches a ready state might not allow enough time for all resources to stabilize or for any dependent processes to complete.
Consider adding a delay or additional validation steps before deleting the HelmRelease to ensure all resources are fully operational.
fi | ||
|
||
kubectl delete helmrelease $release_name -n $namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quote variables in commands to prevent potential word splitting or globbing issues.
It's recommended to quote variables when used in commands to handle cases where variables might contain spaces or special characters.
Apply this diff to quote the variables:
- kubectl delete helmrelease $release_name -n $namespace
+ kubectl delete helmrelease "$release_name" -n "$namespace"
📝 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.
kubectl delete helmrelease $release_name -n $namespace | |
kubectl delete helmrelease "$release_name" -n "$namespace" |
function make_extra_checks(){ | ||
local checks_file="$1" | ||
echo "after exec make $checks_file" | ||
if [[ -n "$checks_file" && -f "$checks_file" ]]; then | ||
echo -e "${YELLOW}Start extra checks with file: ${checks_file}${RESET}" | ||
|
||
fi | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make_extra_checks
function does not execute the checks file.
The make_extra_checks
function currently only prints messages but does not execute any checks from the provided checks_file
. If the intention is to run the checks script, you need to execute it.
Modify the function to execute the checks file:
function make_extra_checks(){
local checks_file="$1"
- echo "after exec make $checks_file"
if [[ -n "$checks_file" && -f "$checks_file" ]]; then
echo -e "${YELLOW}Start extra checks with file: ${checks_file}${RESET}"
+ bash "$checks_file"
fi
}
📝 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.
function make_extra_checks(){ | |
local checks_file="$1" | |
echo "after exec make $checks_file" | |
if [[ -n "$checks_file" && -f "$checks_file" ]]; then | |
echo -e "${YELLOW}Start extra checks with file: ${checks_file}${RESET}" | |
fi | |
} | |
function make_extra_checks(){ | |
local checks_file="$1" | |
if [[ -n "$checks_file" && -f "$checks_file" ]]; then | |
echo -e "${YELLOW}Start extra checks with file: ${checks_file}${RESET}" | |
bash "$checks_file" | |
fi | |
} |
Signed-off-by: Andrei Kvapil <[email protected]>
e5cffbc
to
ef48156
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (1)
hack/testdata/kubernetes/values.yaml (1)
29-62
: Document addon configuration requirementsSeveral suggestions for the addons section:
- Consider making addons opt-in instead of enabled by default
- Document required/recommended values for
valuesOverride
objects- Add validation or warning for empty
ingressNginx.hosts
list- Consider adding examples of common override values for each addon
Example documentation for valuesOverride:
valuesOverride: # Example override values for cert-manager cert-manager: installCRDs: true # Add more common overrides...
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
hack/e2e.application.sh
(5 hunks)hack/testdata/kubernetes/check.sh
(1 hunks)hack/testdata/kubernetes/values.yaml
(1 hunks)hack/testdata/nats/check.sh
(1 hunks)hack/testdata/nats/values.yaml
(1 hunks)hack/testdata/tenant/check.sh
(1 hunks)packages/core/testing/Makefile
(0 hunks)
💤 Files with no reviewable changes (1)
- packages/core/testing/Makefile
🚧 Files skipped from review as they are similar to previous changes (1)
- hack/testdata/nats/values.yaml
🧰 Additional context used
🪛 Shellcheck
hack/testdata/kubernetes/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
hack/testdata/nats/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
hack/testdata/tenant/check.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
🔇 Additional comments (6)
hack/testdata/nats/check.sh (1)
1-1
:
Consider using exit 0
and implement actual checks.
The current implementation has two concerns:
- Using
return
outside a function is incorrect; useexit
for scripts - The script appears to be missing actual NATS-related checks before returning
Let's verify if other check scripts implement actual checks:
Would you like help implementing proper NATS connectivity checks in this script?
🧰 Tools
🪛 Shellcheck
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
hack/testdata/kubernetes/values.yaml (2)
23-25
: Resource quotas are still undefined
The previous review comment about setting default resource limits is still valid and hasn't been addressed.
7-10
: Verify host parameter and control plane replicas configuration
A few concerns about the common parameters:
- Empty host parameter might cause issues in production environments
- Consider adding validation or documentation for minimum control plane replicas (2 is good for HA but should never be less than 1)
- Document supported storage class options
hack/e2e.application.sh (3)
15-30
: LGTM: Good parameter validation and special case handling.
The function includes proper validation of required parameters and clear handling of the special case for tenant-e2e.
97-97
: LGTM: Consistent use of base path variable.
The values file path is properly constructed using the base path variable.
125-125
: LGTM: Improved status checking logic.
Good improvement to support both InstallSucceeded and UpgradeSucceeded as valid success states.
@@ -0,0 +1 @@ | |||
return 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add shebang line for shell specification.
The script is missing a shebang line which is required for proper shell specification and portability.
Add this at the beginning of the file:
+#!/bin/bash
return 0
📝 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.
return 0 | |
#!/bin/bash | |
return 0 |
🧰 Tools
🪛 Shellcheck
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
md0: | ||
minReplicas: 0 | ||
maxReplicas: 10 | ||
instanceType: "u1.medium" | ||
ephemeralStorage: 20Gi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Node group configuration needs adjustment for production use
The current configuration requires changes based on the following findings:
-
minReplicas: 0
is not recommended as:- Other system components like ingress-nginx use
minReplicas: 1
as a safe minimum - The codebase shows that
minReplicas: 1
is standard practice across multiple components - Zero replicas could impact system availability
- Other system components like ingress-nginx use
-
instanceType: "u1.medium"
is a valid value as it's consistently used across multiple components in the codebase (vm-instance, virtual-machine, kubernetes packages) -
The relationship between
minReplicas: 0
andmaxReplicas: 10
should be adjusted to ensure:- A non-zero minimum for high availability
- Alignment with other system components that typically use
minReplicas: 1
Recommendation:
- Set
minReplicas: 1
to ensure continuous availability - Keep
maxReplicas: 10
as it provides sufficient scaling headroom
🔗 Analysis chain
Validate node group configuration parameters
Several configuration values need validation:
minReplicas: 0
might not be suitable for production, especially for a node group running critical components like ingress-nginx- The relationship between
minReplicas
andmaxReplicas
should be validated - Consider documenting supported
instanceType
values
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for instance type definitions and validations
rg -l 'instanceType.*u1\.medium'
# Check for any existing node group configurations
rg -l 'minReplicas.*maxReplicas'
Length of output: 299
Script:
#!/bin/bash
# Check the content of files containing instance type references
rg -A 5 -B 5 'instanceType.*u1\.medium' packages/apps/vm-instance/README.md packages/apps/virtual-machine/README.md
# Search for node group validation logic
rg -l 'validate.*[Nn]ode[Gg]roup|[Nn]ode[Gg]roup.*validate'
# Look for any minReplicas validation or usage
rg -A 3 'minReplicas'
# Search for instance type validation or enum definitions
ast-grep --pattern 'const $_ = {
$$$
u1.medium: $_,
$$$
}'
Length of output: 20165
values_base_path="/hack/testdata/" | ||
checks_base_path="/hack/testdata/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix path definitions to be relative to script location.
The hardcoded paths with leading slashes will cause issues when the script is run from different directories. Use relative paths based on the script's location instead.
Apply this diff:
-values_base_path="/hack/testdata/"
-checks_base_path="/hack/testdata/"
+# Get script directory
+SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
+values_base_path="${SCRIPT_DIR}/testdata/"
+checks_base_path="${SCRIPT_DIR}/testdata/"
📝 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.
values_base_path="/hack/testdata/" | |
checks_base_path="/hack/testdata/" | |
# Get script directory | |
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" | |
values_base_path="${SCRIPT_DIR}/testdata/" | |
checks_base_path="${SCRIPT_DIR}/testdata/" |
checks_file="${checks_base_path}${chart_name}/check.sh" | ||
repo_name="cozystack-apps" | ||
repo_ns="cozy-public" | ||
|
||
release_name="$chart_name-e2e" | ||
install_helmrelease "$release_name" "$TEST_TENANT" "$chart_name" "$repo_name" "$repo_ns" | ||
values_file="${values_base_path}${chart_name}/values.yaml" | ||
|
||
install_tenant $TEST_TENANT $ROOT_NS | ||
check_helmrelease_status $TEST_TENANT $ROOT_NS "${checks_base_path}tenant/check.sh" | ||
|
||
echo -e "${YELLOW}Running tests for chart: $chart_name${RESET}" | ||
|
||
check_helmrelease_status "$release_name" "$TEST_TENANT" | ||
install_helmrelease $release_name $TEST_TENANT $chart_name $repo_name $repo_ns $values_file | ||
check_helmrelease_status $release_name $TEST_TENANT $checks_file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add validation for required files.
The script should validate that the values and checks files exist before proceeding with the installation and checks. Missing files could lead to silent failures.
Add validation before the installation:
checks_file="${checks_base_path}${chart_name}/check.sh"
values_file="${values_base_path}${chart_name}/values.yaml"
+
+# Validate required files exist
+if [[ ! -f "$values_file" ]]; then
+ echo -e "${RED}Values file not found: $values_file${RESET}"
+ exit 1
+fi
+
+if [[ ! -f "$checks_file" ]]; then
+ echo -e "${RED}Checks file not found: $checks_file${RESET}"
+ exit 1
+fi
📝 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.
checks_file="${checks_base_path}${chart_name}/check.sh" | |
repo_name="cozystack-apps" | |
repo_ns="cozy-public" | |
release_name="$chart_name-e2e" | |
install_helmrelease "$release_name" "$TEST_TENANT" "$chart_name" "$repo_name" "$repo_ns" | |
values_file="${values_base_path}${chart_name}/values.yaml" | |
install_tenant $TEST_TENANT $ROOT_NS | |
check_helmrelease_status $TEST_TENANT $ROOT_NS "${checks_base_path}tenant/check.sh" | |
echo -e "${YELLOW}Running tests for chart: $chart_name${RESET}" | |
check_helmrelease_status "$release_name" "$TEST_TENANT" | |
install_helmrelease $release_name $TEST_TENANT $chart_name $repo_name $repo_ns $values_file | |
check_helmrelease_status $release_name $TEST_TENANT $checks_file | |
checks_file="${checks_base_path}${chart_name}/check.sh" | |
repo_name="cozystack-apps" | |
repo_ns="cozy-public" | |
release_name="$chart_name-e2e" | |
values_file="${values_base_path}${chart_name}/values.yaml" | |
# Validate required files exist | |
if [[ ! -f "$values_file" ]]; then | |
echo -e "${RED}Values file not found: $values_file${RESET}" | |
exit 1 | |
fi | |
if [[ ! -f "$checks_file" ]]; then | |
echo -e "${RED}Checks file not found: $checks_file${RESET}" | |
exit 1 | |
fi | |
install_tenant $TEST_TENANT $ROOT_NS | |
check_helmrelease_status $TEST_TENANT $ROOT_NS "${checks_base_path}tenant/check.sh" | |
echo -e "${YELLOW}Running tests for chart: $chart_name${RESET}" | |
install_helmrelease $release_name $TEST_TENANT $chart_name $repo_name $repo_ns $values_file | |
check_helmrelease_status $release_name $TEST_TENANT $checks_file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Summary by CodeRabbit
New Features
Bug Fixes
Chores