Skip to content

Conversation

@Tharsanan1
Copy link
Contributor

@Tharsanan1 Tharsanan1 commented Dec 22, 2025

Purpose

$subject

Summary by CodeRabbit

  • Tests
    • Added validation tests for ConfigMap updates to verify proper reconciliation and configuration changes.
    • Introduced API status tracking tests to confirm accurate counts when managing multiple APIs.
    • Enhanced failure diagnostics with debug logging to capture system state during test failures.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 22, 2025

Walkthrough

The operator integration test workflow was enhanced with two new test steps to verify ConfigMap update triggers and selected APIs status accuracy, plus a debug step to emit diagnostic logs when failures occur.

Changes

Cohort / File(s) Summary
Operator Integration Test Workflow
​.github/workflows/operator-integration-test.yml
Added two new test steps: Test ConfigMap Update Trigger validates configHash changes after ConfigMap patches, and Test Status Accuracy (Selected APIs) verifies selectedAPIs count reflects multiple RestApi instances. Added Debug on failure step to capture diagnostic logs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Additions are straightforward GitHub Actions workflow steps with clear intent
  • Changes are isolated to CI configuration without complex logic or interdependencies
  • Review focus should be on test step correctness and expected assertions:
    • Verify ConfigMap patch syntax and reconciliation wait logic
    • Confirm selectedAPIs count assertions and cleanup verification

Poem

🐇 A workflow springs to life with tests so fine,
ConfigMaps and APIs dance in line,
Debug logs glow when something's wrong,
The operator's heart beats ever strong! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Description check ⚠️ Warning The description is largely incomplete, containing only a placeholder '$subject' in the Purpose section and missing all other required template sections. Complete the description by filling in all required sections: Purpose (with actual explanation and issue links), Goals, Approach, User stories, Documentation, Automation tests, Security checks, Samples, Related PRs, and Test environment details.
Title check ❓ Inconclusive The title 'Operator fixes' is vague and generic, providing no meaningful information about the specific changes or their purpose. Use a more descriptive title that reflects the specific fixes, such as 'Add ConfigMap and API status tests to operator integration workflow' or 'Enhance operator integration tests with ConfigMap and status accuracy checks'.
✅ Passed checks (1 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 88a3b40 and 96e207d.

📒 Files selected for processing (1)
  • .github/workflows/operator-integration-test.yml

Comment on lines +1142 to +1170
- name: Test ConfigMap Update Trigger
run: |
echo "=== Testing ConfigMap Update Trigger ==="
# Get current configHash
INITIAL_HASH=$(kubectl get gateway test-gateway -o jsonpath='{.status.configHash}')
echo "Initial configHash: $INITIAL_HASH"
# Update ConfigMap
echo "Updating ConfigMap..."
kubectl patch configmap test-gateway-config --type merge -p '{"data":{"values.yaml":"# Updated config\nnameOverride: \"\""}}'
# Wait for Operator to reconcile (give it some time to detect change)
# The operator should detect the hash change and update the status
echo "Waiting for operator to process ConfigMap change..."
sleep 60
# Get new configHash
NEW_HASH=$(kubectl get gateway test-gateway -o jsonpath='{.status.configHash}')
echo "New configHash: $NEW_HASH"
if [ "$INITIAL_HASH" == "$NEW_HASH" ]; then
echo "FAILED: configHash did not change after ConfigMap update!"
echo "Expected different hash than $INITIAL_HASH"
exit 1
fi
echo "SUCCESS: configHash updated successfully."
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

The ConfigMap patch replaces the entire configuration, likely breaking the gateway.

Line 1152 replaces values.yaml with minimal content that lacks all the required gateway configuration (controller image, router image, policy engine config, etc.). This would likely cause the gateway to fail, making this test validate a broken state rather than a genuine config update scenario.

Additionally, the fixed 60-second sleep (line 1157) without polling is brittle and slow.

🔎 Recommended fix: Use a non-breaking config update
-          # Update ConfigMap
           echo "Updating ConfigMap..."
-          kubectl patch configmap test-gateway-config --type merge -p '{"data":{"values.yaml":"# Updated config\nnameOverride: \"\""}}'
+          # Make a small, non-breaking change like adding a comment or annotation
+          CURRENT_CONFIG=$(kubectl get configmap test-gateway-config -o jsonpath='{.data.values\.yaml}')
+          UPDATED_CONFIG=$(echo "$CURRENT_CONFIG" | sed '1s/^/# Test update '"$(date +%s)"'\n/')
+          kubectl patch configmap test-gateway-config --type merge -p "{\"data\":{\"values.yaml\":\"$UPDATED_CONFIG\"}}"
           
-          # Wait for Operator to reconcile (give it some time to detect change)
-          # The operator should detect the hash change and update the status
-          echo "Waiting for operator to process ConfigMap change..."
-          sleep 60 
+          # Poll for hash change instead of fixed sleep
+          echo "Polling for configHash change..."
+          for i in {1..30}; do
+            NEW_HASH=$(kubectl get gateway test-gateway -o jsonpath='{.status.configHash}')
+            if [ "$INITIAL_HASH" != "$NEW_HASH" ]; then
+              break
+            fi
+            echo "Attempt $i/30: Hash unchanged, waiting..."
+            sleep 2
+          done

Comment on lines +1171 to +1241
- name: Test Status Accuracy (Selected APIs)
run: |
echo "=== Testing Status Accuracy (SelectedAPIs) ==="
# Current state: test-gateway has 'test-api' (1 API)
# Verify initial count
COUNT=$(kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}')
echo "Initial SelectedAPIs count: $COUNT"
if [ "$COUNT" != "1" ]; then
echo "FAILED: Expected 1 selected API, got $COUNT"
exit 1
fi
# Add a second API
echo "Creating second API (status-test-api)..."
cat <<EOF | kubectl apply -f -
apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: RestApi
metadata:
name: status-test-api
namespace: default
spec:
displayName: status-test-api
version: v1.0
context: /status-test
upstream:
main:
url: http://httpbin.default.svc.cluster.local:80
operations:
- method: GET
path: /get
EOF
echo "Waiting for status-test-api to be programmed..."
kubectl wait --for=condition=Programmed restapi/status-test-api --timeout=120s
# Wait for Gateway status update
sleep 10
# Verify count incremented
COUNT=$(kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}')
echo "SelectedAPIs count after adding API: $COUNT"
if [ "$COUNT" != "2" ]; then
echo "FAILED: Expected 2 selected APIs, got $COUNT"
kubectl get restapi
exit 1
fi
# Delete second API
echo "Deleting status-test-api..."
kubectl delete restapi status-test-api
echo "Waiting for deletion..."
kubectl wait --for=delete restapi/status-test-api --timeout=60s
# Wait for Gateway status update
sleep 10
# Verify count decremented
COUNT=$(kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}')
echo "SelectedAPIs count after deleting API: $COUNT"
if [ "$COUNT" != "1" ]; then
echo "FAILED: Expected 1 selected API, got $COUNT"
exit 1
fi
echo "SUCCESS: Status SelectedAPIs updated accurately."
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion | 🟠 Major

Replace fixed sleeps with polling to improve test reliability.

Lines 1209 and 1229 use fixed 10-second sleeps to wait for the gateway status to update. This creates a race condition—if the operator takes longer than 10 seconds to reconcile, the test becomes flaky.

🔎 Suggested improvement: Poll for status changes

For line 1209, replace:

-          # Wait for Gateway status update
-          sleep 10
-          
-          # Verify count incremented
           COUNT=$(kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}')
+          
+          # Poll for status update with timeout
+          echo "Polling for selectedAPIs count to update..."
+          for i in {1..20}; do
+            COUNT=$(kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}')
+            if [ "$COUNT" == "2" ]; then
+              break
+            fi
+            echo "Attempt $i/20: Count is $COUNT, waiting..."
+            sleep 2
+          done
+          
           echo "SelectedAPIs count after adding API: $COUNT"

Apply similar polling logic at line 1229 for the deletion verification.

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In .github/workflows/operator-integration-test.yml around lines 1171 to 1241 the
script uses fixed 10s sleeps at lines ~1209 and ~1229 which makes the test
flaky; replace each fixed sleep with a polling loop that repeatedly queries
kubectl get gateway test-gateway -o jsonpath='{.status.selectedAPIs}' (or uses
kubectl wait with a JSONPath/condition if available), compare against the
expected value (2 after creation, 1 after deletion), retry at short intervals
(e.g., 1s) with an overall timeout (e.g., 60–120s), and fail if the timeout is
reached; ensure you remove the hardcoded sleep lines and add the polling loop
before the verification checks so the script only proceeds when the Gateway
status has actually updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant