docs: reorder readme steps for devcontainer#178
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughDocumentation-only change to ChangesDevcontainer README reorganization
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
c8382cc to
94d6b98
Compare
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment Thanks for integrating Codecov - We've got you covered ☂️ |
94d6b98 to
49ec75f
Compare
…eouts (#187) * fix(ci): free runner disk after image loads; diagnose e2e rollout timeouts External PR #178's run (28623232380) failed with the controller rollout timing out after a fresh install in the image-refresh lane. The job summary shows the runner bottomed out at 1.4GB free disk - inside the kubelet eviction threshold of the k3d node, the exact image-GC / pod-not-ready failure mode load-image.sh pins against. Nothing about the failure was fork-specific: the untrusted path (artifact handoff, local build, import) worked end to end. - Delete the multi-GB docker-load tarballs right after loading in every consumer job; they were sitting on disk for the whole e2e run. - fail-fast: false on the e2e matrix: quickstart's failure cancelled E2E (full) mid-run, losing its signal and erroring its report upload. - deploy-controller.sh: widen the rollout wait to 300s (fresh installs also wait on cert-manager issuing the admission cert) and dump node conditions, pods, describe, and events on timeout so the next occurrence names its cause in the log. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(e2e): stop k3d DiskPressure evictions with absolute kubelet thresholds The diagnostics added in the previous commit named the cause directly: the k3d node reported DiskPressure and evicted/rejected the controller pod, while the runner still had 3.3GB free. k3s defaults kubelet eviction to nodefs.available<5% - ~3.6GB of a 72GB CI disk - and the pressure condition then lingers for the default 5m transition period, longer than the rollout wait. - start-cluster.sh: absolute eviction thresholds (1Gi) and a 30s pressure transition period on all k3d nodes. Percentages don't express "actually almost full" when the node shares the host disk. (Invalidates _cluster-ready: next local e2e run rebuilds the cluster.) - ci.yml e2e job: free ~18GB of unused preinstalled toolchains (android, CodeQL, dotnet) before downloading artifacts. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
49ec75f to
cf608e4
Compare
|
Thanks for your first contribution @scott-david-walker! |
Description
Small change that reflects the order of the steps when running a dev container
Type of Change
Summary by CodeRabbit