test: gate ablytest sandbox provisioning behind an internal build tag#706
test: gate ablytest sandbox provisioning behind an internal build tag#706SimonWoolf wants to merge 1 commit into
Conversation
The ablytest package is importable, so anything it exports is callable by downstream consumers. Those helpers are intended only for running ably-go's own integration tests, not as a supported API. We don't want to actually put any security barries in place, because we want SDK development to be open to all, and there's no way to verify whether a given test app will be used for SDK development or not. But we can at least add a build tag that makes it at obvious that this is not the intended usecase. This is not a security boundary (the code can be copied, or an external caller can just specify that tag), but rather a polite request, intended to avoid misunderstandings and unintentional reliance. CI and CONTRIBUTING are updated to pass -tags=integration,ably_internal_sdk_tests_only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (23)
WalkthroughThis PR introduces a new Go build tag, ChangesBuild tag gating for integration tests
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
|
replacing with #707 |
The ablytest package is importable, so anything it exports is callable by downstream consumers. Those helpers are intended only for running ably-go's own integration tests, not as a supported API.
We don't want to actually put any security barries in place, because we want SDK development to be open to all, and there's no way to verify whether a given test app will be used for SDK development or not. But we can at least add a build tag that makes it at obvious that this is not the intended usecase.
This is not a security boundary (the code can be copied, or an external caller can just specify that tag), but rather a polite request, intended to avoid misunderstandings and unintentional reliance.
Summary by CodeRabbit