Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/workflows/kind-ci-automation.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@ on:
branches:
- "master"
- "v*"
push:
branches:
- "master"
- "v*"

env:
IMG: gitops-operator:test
Expand Down
98 changes: 98 additions & 0 deletions hack/scripts/eks-cluster.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
#!/usr/bin/env bash
#
# Manage an AWS EKS cluster (3 nodes) suitable for Argo CD HA.
#
# Usage:
# ./eks-cluster.sh create [CLUSTER_NAME] [REGION] [AWS_PROFILE]
# ./eks-cluster.sh delete [CLUSTER_NAME] [REGION] [AWS_PROFILE]
# ./eks-cluster.sh status [CLUSTER_NAME] [REGION] [AWS_PROFILE]
#
# Defaults:
# CLUSTER_NAME = argocd-xks
# REGION = us-east-1
# AWS_PROFILE = default

set -euo pipefail

usage() {
echo "Usage: $0 {create|delete|status} [CLUSTER_NAME] [REGION]"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 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/**' . || true

Repository: 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

exit 1
}

[[ $# -ge 1 ]] || usage

ACTION="$1"; shift
CLUSTER_NAME="${1:-argocd-xks}"
REGION="${2:-us-east-1}"
AWS_PROFILE="${3:-default}"

K8S_VERSION="1.30"
NODE_TYPE="m5.xlarge"
NODE_COUNT=3
NODE_VOLUME_SIZE=100

required_cmds=(aws eksctl)
[[ "${ACTION}" == "create" || "${ACTION}" == "status" ]] && required_cmds+=(kubectl)
for cmd in "${required_cmds[@]}"; do
if ! command -v "${cmd}" &>/dev/null; then
echo "ERROR: ${cmd} not found in PATH" >&2
exit 1
fi
done

cmd_create() {
echo "==> Creating EKS cluster: ${CLUSTER_NAME} in ${REGION}"
echo " Kubernetes ${K8S_VERSION}, ${NODE_COUNT}x ${NODE_TYPE}, ${NODE_VOLUME_SIZE}GiB volumes"

eksctl create cluster --profile ${AWS_PROFILE} \
--name "${CLUSTER_NAME}" \
--region "${REGION}" \
--version "${K8S_VERSION}" \
--nodegroup-name "argocd-workers" \
--node-type "${NODE_TYPE}" \
--nodes "${NODE_COUNT}" \
--nodes-min "${NODE_COUNT}" \
--nodes-max "${NODE_COUNT}" \
--node-volume-size "${NODE_VOLUME_SIZE}" \
--managed \
--with-oidc \
--ssh-access=false \
--asg-access

echo "==> Cluster ready"
kubectl get nodes -o wide
}

cmd_delete() {
echo "==> This will DELETE cluster '${CLUSTER_NAME}' in ${REGION} and all associated resources"
if [[ "${FORCE:-false}" != "true" ]]; then
read -rp " Continue? [y/N] " confirm
[[ "${confirm}" =~ ^[Yy]$ ]] || { echo "Aborted."; exit 0; }
fi

echo "==> Deleting EKS cluster: ${CLUSTER_NAME}"
eksctl delete cluster \
--name "${CLUSTER_NAME}" \
--region "${REGION}" \
--wait

echo "==> Cleanup complete"
}

cmd_status() {
echo "==> Cluster: ${CLUSTER_NAME} (${REGION})"
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)"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 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 || true

Repository: 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:


🌐 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:


🌐 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:


🌐 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:


🌐 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:


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.

else
echo " Cluster not found"
Comment on lines +84 to +89

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 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.sh

Repository: 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:


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.

fi
}

case "${ACTION}" in
create) cmd_create ;;
delete) cmd_delete ;;
status) cmd_status ;;
*) usage ;;
esac
Loading