🐛 fix start-minikube action to pass through memory input#576
Conversation
|
Warning Review limit reached
More reviews will be available in 57 minutes and 47 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe start-minikube GitHub Action is updated to forward the configurable ChangesMinikube Memory Parameter Pass-through
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
The start-minikube action accepts a `memory` input but was ignoring it — the medyagh/setup-minikube call hardcoded `memory: 8000`. This meant callers passing `memory: "max"` (like editor-extensions E2E) got exactly 8000MB regardless of available runner memory. With the full Konveyor stack (hub, postgres, kai, llm-proxy, llemulator, operator, ingress) all sharing 8GB, the system runs under significant memory pressure causing flaky hub timeouts in downstream E2E tests. Fixes konveyor#575 Signed-off-by: ibolton336 <ibolton@redhat.com>
041ed29 to
b4f829a
Compare
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Signed-off-by: ibolton336 <ibolton@redhat.com>
Summary
The
start-minikubeaction accepts amemoryinput but was ignoring it — themedyagh/setup-minikubecall hardcodedmemory: 8000. This meant callers passingmemory: "max"(like editor-extensions E2E workflows) got exactly 8000MB regardless of available runner memory.Problem
With the full Konveyor stack (hub, postgres, kai-api, kai-db, llm-proxy, llemulator, operator, nginx ingress) all sharing a hardcoded 8GB, the system runs under significant memory pressure on GitHub Actions runners. This causes:
Fix
One-line change:
memory: 8000→memory: ${{ inputs.memory }}This respects the caller's intent. When
memoryis empty string (default),medyagh/setup-minikubeuses its own default. When"max"is passed, minikube uses all available RAM.Fixes #575
Summary by CodeRabbit