New scenarios K8S_LIB_INJECTION_APPSEC#6237
Conversation
|
|
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🔗 Commit SHA: 1e80dc9 | Docs | Datadog PR Page | Was this helpful? Give us feedback! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5e373a21e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| try: | ||
| weblog_response = requests.get(weblog_url, headers={"user-agent": "dd-test-scanner-log"}, timeout=10) | ||
| logger.info(f"Weblog response status: {weblog_response.status_code}") | ||
| except Exception as e: | ||
| logger.warning(f"Weblog request failed with exception: {e}") | ||
|
|
There was a problem hiding this comment.
Fail test when weblog/agent calls error
Swallowing request exceptions here means the disabled-by-default test can pass even when the weblog or test agent is unreachable: _check_appsec_traces logs the failure and eventually returns False, so test_appsec_disabled_by_default will accept a broken setup as “disabled.” This can mask real regressions in the cluster or tracing pipeline. Consider re-raising on request failures or asserting that the weblog/agent calls succeed (e.g., require at least one trace before concluding AppSec is disabled).
Useful? React with 👍 / 👎.
Implement new scenarios
K8S_LIB_INJECTION_APPSEC_ENABLEDandK8S_LIB_INJECTION_APPSEC_DISABLED