CI: Github action job tests for xks on push to master and release branch - #1217
CI: Github action job tests for xks on push to master and release branch#1217anandrkskd wants to merge 8 commits into
Conversation
assisted-by: claudecode Signed-off-by: Anand Kumar Singh <anandrkskd@gmail.com>
Signed-off-by: Anand Kumar Singh <anandrkskd@gmail.com>
openshift-ci
Bot
added
do-not-merge/work-in-progress
kind/enhancement
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
📝 WalkthroughWalkthroughAdds an EKS cluster management script with create, delete, and status commands, and extends the Kind CI workflow to run on pushes to ChangesEKS cluster management
Kind CI trigger
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant eksctl
participant kubectl
Operator->>eksctl: Create or delete EKS cluster
eksctl-->>Operator: Return operation status
Operator->>kubectl: Query node details
kubectl-->>Operator: Return node status
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
Signed-off-by: Anand Kumar Singh <anandrkskd@gmail.com>
anandrkskd
changed the title
Signed-off-by: Anand Kumar Singh <anandrkskd@gmail.com>
Signed-off-by: Anand Kumar Singh <anandrkskd@gmail.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@hack/scripts/eks-cluster.sh`:
- Line 18: Update usage() to document the optional fourth AWS profile argument,
then pass the quoted AWS_PROFILE value via --profile on every eksctl create,
delete, and get invocation so all operations target the selected profile
consistently.
- Around line 84-89: Update the cluster status checks around eksctl get cluster
and kubectl get nodes to preserve stderr and surface authentication, permission,
network, and configuration failures. Remove the unconditional stderr suppression
and ensure only an explicit missing-cluster result produces “Cluster not found,”
while kubectl’s fallback message is used only for the intended not-configured
condition.
- Line 87: Update the node-reporting command in the EKS cluster script to target
the requested CLUSTER_NAME in REGION rather than kubectl’s active kubeconfig
context, using the script’s configured AWS_PROFILE as applicable. Preserve the
existing wide node output and fallback message when kubectl is unavailable or
the target context cannot be configured.
🪄 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: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 75ce4b4d-bf1b-4f76-9bc0-307f41f0abc5
📒 Files selected for processing (2)
.github/workflows/kind-ci-automation.yamlhack/scripts/eks-cluster.sh
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
argoproj-labs/argocd-operator(manual)
| set -euo pipefail | ||
|
|
||
| usage() { | ||
| echo "Usage: $0 {create|delete|status} [CLUSTER_NAME] [REGION]" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file exists and relevant lines =="
cat -n hack/scripts/eks-cluster.sh | sed -n '1,130p'
echo
echo "== occurrences of eksctl/AWS_PROFILE in file =="
rg -n "eksctl|AWS_PROFILE|usage" hack/scripts/eks-cluster.sh
echo
echo "== diff/stat context if available =="
git diff --stat || true
git diff -- hack/scripts/eks-cluster.sh | sed -n '1,220p' || true
echo
echo "== find related docs/scripts mentioning AWS_PROFILE profiles =="
rg -n "AWS_PROFILE|--profile|eks-cluster" --glob '!vendor/**' --glob '!dist/**' . || trueRepository: redhat-developer/gitops-operator
Length of output: 4632
Pass AWS_PROFILE through every eksctl call.
delete and status still omit --profile, so calling this script with a custom profile can list/delete the incorrectly-targeted cluster. Update usage() to mention the 4th argument, quote "${AWS_PROFILE}", and append --profile "${AWS_PROFILE}" to the create, delete, and get eksctl commands.
🤖 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 `@hack/scripts/eks-cluster.sh` at line 18, Update usage() to document the
optional fourth AWS profile argument, then pass the quoted AWS_PROFILE value via
--profile on every eksctl create, delete, and get invocation so all operations
target the selected profile consistently.
Source: Linters/SAST tools
| if eksctl get cluster --name "${CLUSTER_NAME}" --region "${REGION}" 2>/dev/null; then | ||
| echo "" | ||
| echo "==> Nodes:" | ||
| kubectl get nodes -o wide 2>/dev/null || echo " (kubectl not configured for this cluster)" | ||
| else | ||
| echo " Cluster not found" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -e
echo "== file preview =="
sed -n '1,140p' hack/scripts/eks-cluster.sh
echo
echo "== related usage patterns =="
rg -n "eksctl|not configured|Cluster not found|kubectl get nodes" hack scripts . --glob '!vendor/**' --glob '!node_modules/**' 2>/dev/null || true
echo
echo "== script outline / relevant env =="
rg -n "CLUSTER_NAME|REGION|eksctl get cluster|kubectl get nodes" hack/scripts/eks-cluster.shRepository: redhat-developer/gitops-operator
Length of output: 7783
🌐 Web query:
eksctl commands cluster status get cluster exit codes no cluster found behavior
💡 Result:
When you run the eksctl get cluster command and the specified cluster is not found, the tool typically returns a non-zero exit code, indicating failure [1]. The error output will explicitly state that the cluster could not be described, often manifesting as a ResourceNotFoundException from the underlying AWS EKS API [2][3][4]. Key behaviors associated with this scenario include: 1. Exit Codes: Unlike commands that might exit with code 0 even when no resources are returned (such as some list operations), attempts to get a specific cluster that does not exist generally result in a non-zero exit code [1]. This allows you to use the command reliably in scripts to check for existence via the exit status. 2. Error Messages: You will typically see an error message such as: [✖] unable to describe control plane "cluster-name": ResourceNotFoundException: No cluster found for name: cluster-name [3][4]. 3. Region Mismatches: A "no cluster found" error is frequently caused by a region mismatch [5]. If the cluster exists but the AWS environment's default region (or the region specified via the --region flag) does not match the cluster's actual region, eksctl will be unable to find it [6][5]. 4. Troubleshooting: * Verify the region: Ensure you are targeting the correct AWS region where the cluster was created [5]. * Check permissions: Ensure your AWS credentials have the necessary permissions to call the EKS DescribeCluster API. * Debugging: You can use the -v 4 flag (e.g., eksctl get cluster --name -v 4) to increase verbosity and see more details about the API requests being made [3]. If you are using eksctl in an automated pipeline, you should treat a non-zero exit code from eksctl get cluster as a definitive indication that the cluster could not be accessed or does not exist in the configured region.
Citations:
- 1: eksctl get nodegroup exist with code 0 when nodegroup doesn't exist eksctl-io/eksctl#2728
- 2: Better error messages when region not set eksctl-io/eksctl#2980
- 3: eksctl get cluster returns ResourceNotFoundException while cluster is provisioning eksctl-io/eksctl#715
- 4: Cluster deletion does not cleanup AWS CF stack, if the stack creation failed. eksctl-io/eksctl#1967
- 5: https://barnybaron.com/article/20240619-eksctl-no-clusters-found-region-mismatch/
- 6: eksctl get clusters - No clusters found from bootstrap node eksctl-io/eksctl#2031
Do not suppress command failures in the status path.
Redirecting stderr to /dev/null hides authentication, AWS permission, network, or malformed-configuration failures, so eksctl get cluster can be reported as “Cluster not found” and kubectl get nodes as “not configured.” Preserve stderr and only treat the explicit missing-cluster response as not-found.
🤖 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 `@hack/scripts/eks-cluster.sh` around lines 84 - 89, Update the cluster status
checks around eksctl get cluster and kubectl get nodes to preserve stderr and
surface authentication, permission, network, and configuration failures. Remove
the unconditional stderr suppression and ensure only an explicit missing-cluster
result produces “Cluster not found,” while kubectl’s fallback message is used
only for the intended not-configured condition.
| if eksctl get cluster --name "${CLUSTER_NAME}" --region "${REGION}" 2>/dev/null; then | ||
| echo "" | ||
| echo "==> Nodes:" | ||
| kubectl get nodes -o wide 2>/dev/null || echo " (kubectl not configured for this cluster)" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and inspect the referenced script around the reported line and surrounding EKS setup.
if [ -f hack/scripts/eks-cluster.sh ]; then
wc -l hack/scripts/eks-cluster.sh
sed -n '1,140p' hack/scripts/eks-cluster.sh | cat -n
else
echo "hack/scripts/eks-cluster.sh not found"
find . -name 'eks-cluster.sh' -type f
fi
printf '\n--- references to CLUSTER_NAME, REGION, AWS_PROFILE, kubectl get nodes ---\n'
rg -n 'CLUSTER_NAME|REGION|AWS_PROFILE|kubectl get nodes|kubeconfig|aws eks|aws configure|context' hack/scripts/eks-cluster.sh .github hack || trueRepository: redhat-developer/gitops-operator
Length of output: 8437
🌐 Web query:
eksctl create cluster prints KUBECONFIG kubectl get nodes current context
💡 Result:
When you run the command eksctl create cluster, the tool automatically updates your kubeconfig file with the credentials and context for the new EKS cluster [1][2]. By default, eksctl writes this configuration to your primary kubeconfig file, which is either the path specified in your KUBECONFIG environment variable or ~/.kube/config if that variable is unset [1][2]. As part of this process, eksctl sets the new cluster's context as the current context in your kubeconfig by default [1][2]. Because your kubeconfig has been updated and the context has been switched, running kubectl get nodes immediately after the cluster creation finishes should target your new EKS cluster [3][4]. Key behavior details: * Automatic Updates: eksctl automatically handles the merge of cluster details into your existing kubeconfig [1][2]. * Default Context: The --set-kubeconfig-context flag defaults to true, meaning the current context is automatically switched to the newly created cluster [1][5]. If you prefer to disable this behavior, you can set --set-kubeconfig-context=false [6]. * Customization: You can override the destination kubeconfig file using the --kubeconfig flag [1][2]. If you ever need to regenerate or manually update your configuration for an existing cluster, you can use the command: eksctl utils write-kubeconfig --cluster= [6] Alternatively, you can use the AWS CLI command: aws eks update-kubeconfig --region --name [7]
Citations:
- 1: https://mhausenblas.info/eksctl/usage/creating-and-managing-clusters/
- 2: https://docs.aws.amazon.com/eks/latest/eksctl/creating-and-managing-clusters.html
- 3: https://github.com/eksctl-io/eksctl/
- 4: https://github.com/eksctl-io/eksctl/blob/main/README.md
- 5: https://gist.github.com/WillHoule/ea693d6a760cc39811644cc0f7fcf8ec
- 6: https://mhausenblas.info/eksctl/intro/
- 7: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
🌐 Web query:
eksctl print current-context false KUBECONFIG update-kubeconfig AWS_PROFILE
💡 Result:
To manage your Kubernetes configuration with eksctl and the AWS CLI, please refer to the following clarifications and commands. There is no command named eksctl print current-context. To view the current context of your kubeconfig file, use the standard Kubernetes CLI command [1][2]: kubectl config current-context If you are using eksctl to write to your kubeconfig and want to prevent it from automatically switching your current context to the new cluster, use the --set-kubeconfig-context=false flag [3][4]: eksctl utils write-kubeconfig --cluster= --set-kubeconfig-context=false Regarding AWS profiles and updating your kubeconfig, the AWS CLI is the standard tool for this task [5][6]. To update your kubeconfig while specifying a particular AWS CLI profile, use the following command [5]: aws eks update-kubeconfig --name --profile When using eksctl directly to write kubeconfig entries, you can ensure a specific AWS profile is associated with that entry by using the --profile flag [7][8]: eksctl utils write-kubeconfig --cluster= --profile Note that if you use the KUBECONFIG environment variable to point to a specific file, tools like eksctl and the AWS CLI will respect this path by default when reading or writing configuration [3][9][5]. If the variable is not set, they default to ~/.kube/config [3][5].
Citations:
- 1: Prompt for Username and Password when running "kubectl get all" eksctl-io/eksctl#164
- 2: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_config/kubectl_config_current-context/
- 3: https://docs.aws.amazon.com/eks/latest/eksctl/creating-and-managing-clusters.html
- 4: https://mhausenblas.info/eksctl/intro/
- 5: https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html
- 6: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
- 7: Add AWS_PROFILE env to kubeconfig eksctl-io/eksctl#1407
- 8: write-kubeconfig should also write out the value of AWS_PROFILE when set via the environment eksctl-io/eksctl#4483
- 9: https://docs.aws.amazon.com/pdfs/eks/latest/eksctl/AmazonEksEksctlDocs.pdf
🌐 Web query:
source weaveworks eksctl create-cluster code print current context default
💡 Result:
When you run the command eksctl create cluster, eksctl automatically adds the new cluster's configuration to your kubeconfig file (located by default at ~/.kube/config) [1][2]. By default, eksctl also updates your kubeconfig file to set the newly created cluster as the current context [1][3][2]. This behavior is controlled by the --set-kubeconfig-context flag, which is enabled by default [1][3][4]. If you wish to prevent eksctl from overwriting your current context, you can explicitly set this flag to false: eksctl create cluster --set-kubeconfig-context=false When this option is true (the default), if a context is already set in your kubeconfig file, it will be overwritten by the new cluster's context [1][2].
Citations:
- 1: https://docs.aws.amazon.com/eks/latest/eksctl/creating-and-managing-clusters.html
- 2: https://docs.aws.amazon.com/pdfs/eks/latest/eksctl/AmazonEksEksctlDocs.pdf
- 3: https://gist.github.com/WillHoule/ea693d6a760cc39811644cc0f7fcf8ec
- 4: improve create cluster --help eksctl-io/eksctl#298
🌐 Web query:
weaveworks eksctl create cluster KUBECONFIG print current context source
💡 Result:
When using eksctl to create a cluster, the tool automatically updates your KUBECONFIG file (by default located at ~/.kube/config or the path specified by the KUBECONFIG environment variable) with the new cluster's credentials [1][2][3]. By default, eksctl also automatically sets the newly created cluster's context as the current context in your kubeconfig file [1][4][3]. Key points regarding kubeconfig management during cluster creation: - Automatic Updates: eksctl adds the necessary configuration to your kubeconfig file automatically [1][5]. - Current Context: The --set-kubeconfig-context flag, which defaults to true, ensures the new cluster's context is set as the current one [1][3]. - Controlling Behavior: You can disable this behavior or customize the output using flags: --write-kubeconfig=false: Disables automatic writing to the kubeconfig file [6][3]. --set-kubeconfig-context=false: Prevents the new cluster from becoming the default context [1][3]. --kubeconfig=: Specifies a custom path to write the configuration [1][6]. - Managing Existing Clusters: If you need to regenerate or update your local kubeconfig for an existing cluster at any time, you can use the following command: eksctl utils write-kubeconfig --cluster --region [6][7] To verify your current context after creation, you can use the command: kubectl config current-context [6]
Citations:
- 1: https://docs.aws.amazon.com/eks/latest/eksctl/creating-and-managing-clusters.html
- 2: https://github.com/weaveworks/eksctl/blob/main/README.md
- 3: https://mhausenblas.info/eksctl/usage/creating-and-managing-clusters/
- 4: improve create cluster --help eksctl-io/eksctl#298
- 5: https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html
- 6: https://mhausenblas.info/eksctl/intro/
- 7: https://adhdecode.com/cheatsheets/eksctl/
🌐 Web query:
AWS EKS user guide aws eks update-kubeconfig --kubeconfig - --profile --region current context
💡 Result:
The aws eks update-kubeconfig command is used to configure kubectl to connect to an Amazon EKS cluster [1][2]. Regarding the specific flags and behavior you mentioned: --kubeconfig - When you specify --kubeconfig - (a hyphen), the AWS CLI redirects the generated kubeconfig output to standard output (stdout) instead of writing it to a file. This is functionally equivalent to the --dry-run option [3][4]. --profile and --region These are standard global options for the AWS CLI [3][5]. --profile allows you to specify a named profile from your AWS credentials file to use for authentication when calling the EKS API. --region specifies the AWS region where the EKS cluster is located [3]. If these are not provided, the command defaults to the values configured in your AWS CLI environment (e.g., via aws configure or environment variables). Current Context When you run update-kubeconfig, the command automatically updates your kubeconfig file and sets the newly created or updated cluster entry as the current context [2]. If you are working with multiple clusters, this ensures that subsequent kubectl commands are directed to the most recently updated cluster by default [2]. Common Usage Example To update your local configuration for a specific cluster in a specific region using a specific profile: aws eks update-kubeconfig --name --region --profile To preview the configuration in your terminal without modifying any files: aws eks update-kubeconfig --name --kubeconfig -
Citations:
- 1: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
- 2: https://github.com/aws/aws-cli/blob/develop/awscli/examples/eks/update-kubeconfig/_description.rst
- 3: https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html
- 4: https://github.com/aws/aws-cli/blob/develop/awscli/customizations/eks/update_kubeconfig.py
- 5: https://awscli.amazonaws.com/v2/documentation/api/2.8.7/reference/eks/update-kubeconfig.html
Bind node reporting to the requested EKS cluster.
kubectl reads the current kubeconfig context, but this script lets users pass AWS_PROFILE, and multiple clusters/profiles can share a kubeconfig. Ensure kubectl get nodes targets ${CLUSTER_NAME} in ${REGION} (e.g., via kubectl config use-context or eksctl write-kubeconfig) instead of relying on the active context.
🤖 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 `@hack/scripts/eks-cluster.sh` at line 87, Update the node-reporting command in
the EKS cluster script to target the requested CLUSTER_NAME in REGION rather
than kubectl’s active kubeconfig context, using the script’s configured
AWS_PROFILE as applicable. Preserve the existing wide node output and fallback
message when kubectl is unavailable or the target context cannot be configured.
1 participant
What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
This PR adds CI Jobs for push to master and release branch, We are going to use existing kind automation for cluster for testing with 3 nodes.
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #?
Test acceptance criteria:
How to test changes / Special notes to the reviewer: