fix(acs-ci): bound GCS preflight request - #211
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 8 remain after this review. WalkthroughThe GCS preflight check now validates bucket existence with ChangesGCS preflight validation
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~3 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The preflight now validates bucket metadata without enumerating the logs prefix, with no merge-blocking risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
| echo "GCS: gsutil ls gs://$GCS_BUCKET/logs/" | ||
| if /opt/gsutil/bin/gsutil ls "gs://$GCS_BUCKET/logs/" >/dev/null 2>"$gcs_error"; then | ||
| echo "GCS: gsutil ls -b gs://$GCS_BUCKET" | ||
| if /opt/gsutil/bin/gsutil ls -b "gs://$GCS_BUCKET" >/dev/null 2>"$gcs_error"; then |
There was a problem hiding this comment.
This check no longer verifies the existence of the logs subdirectory, only the bucket itself. This seems like a weaker preflight check that could allow subsequent steps to fail if they depend on that directory. Is this change intended?
Use gsutil bucket metadata for the ACS preflight instead of enumerating the entire logs prefix. This keeps the connectivity check bounded while still exercising the sandbox CA bundle and GCS provider.
Summary by CodeRabbit