reproducer no group defined in OIDC user#98
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughUpdate .env to use Elasticsearch/Kibana 9.3.3, switch plugin retrieval to API-based Dockerfiles, bump ReadonlyREST plugin versions to 1.69.1 (set ROR_ES_VERSION=1.69.1), enable non-interactive env values, increase Kibana ROR log level to trace, and remove a Keycloak user's group memberships. Changes
Sequence Diagram(s)(Skipped — changes are configuration updates and small control-flow tweaks that do not introduce a new multi-component interaction flow warranting a sequence diagram.) Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested reviewers
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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@ror-demo-cluster/.env-showcase`:
- Around line 8-14: The ROR plugin version variables (ROR_ES_VERSION /
ROR_KBN_VERSION) are incompatible with the ES/KBN versions (ES_VERSION /
KBN_VERSION) and cause download failures; update .env-showcase so the ROR
versions published for ES/KBN 9.3.3 are used or else change ES_VERSION and
KBN_VERSION to a release that supports ROR 1.68.0: edit the ES_VERSION /
KBN_VERSION or ROR_ES_VERSION / ROR_KBN_VERSION accordingly (these values are
consumed by the es-ror build args and install-ror-es-using-api.sh path), ensure
Dockerfile-use-ror-binaries-from-api still aligns with those variables, leave
ES_ROR_FILE / KBN_ROR_FILE unset if using the API Dockerfile, and verify the
chosen ROR/ES/KBN combination successfully downloads from api.beshu.tech before
merging.
In `@ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml`:
- Line 17: The config sets readonlyrest_kbn.logLevel to trace which is fine for
reproducing RORDEV-2009 but must not land in master; change this value back to a
safe level (e.g., info or warn) before merging or gate the trace setting behind
an environment-specific override (e.g., check an env var or branch flag) so that
readonlyrest_kbn.logLevel is only trace in local/dev runs and never in
production/master; reference the readonlyrest_kbn.logLevel entry in the YAML and
add a short comment explaining the temporary nature of the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: dcfd2ba8-bb93-4c53-b82a-3f356afd6584
📒 Files selected for processing (3)
ror-demo-cluster/.env-showcaseror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.ymlror-demo-cluster/conf/keycloak/ror-realm.json
| xpack.encryptedSavedObjects.encryptionKey: "min-32-byte-long-strong-encryption-key" | ||
|
|
||
| readonlyrest_kbn.logLevel: info | ||
| readonlyrest_kbn.logLevel: trace |
There was a problem hiding this comment.
Trace logging appropriate for reproducer.
Bumping readonlyrest_kbn.logLevel to trace is reasonable for this RORDEV-2009 reproducer to capture why the metadata request is rejected for extUser1. Just make sure this change is not merged to master as-is — trace is noisy and may surface sensitive auth/token data in logs in a showcase environment.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml` at line 17,
The config sets readonlyrest_kbn.logLevel to trace which is fine for reproducing
RORDEV-2009 but must not land in master; change this value back to a safe level
(e.g., info or warn) before merging or gate the trace setting behind an
environment-specific override (e.g., check an env var or branch flag) so that
readonlyrest_kbn.logLevel is only trace in local/dev runs and never in
production/master; reference the readonlyrest_kbn.logLevel entry in the YAML and
add a short comment explaining the temporary nature of the change.
Summary by CodeRabbit