Add default MC validation tests to upgrade#583
Add default MC validation tests to upgrade#583dbasunag merged 19 commits intoopendatahub-io:mainfrom
Conversation
📝 WalkthroughWalkthroughRemoved manual ConfigMap cleanup utility and its usages in fixtures. Updated default model catalog tests to import constants, mark two tests as post-upgrade, and add assertions for default catalog id and name. No public API changes beyond deleting an internal utility function. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
tests/model_registry/model_catalog/test_default_model_catalog.py (1)
85-86: DRY: reuse the existing helper to validate the default catalog.You already import
validate_default_catalog; use it here to keep the checks consistent with Line 37.Apply:
- assert result[0]["id"] == DEFAULT_CATALOG_ID - assert result[0]["name"] == DEFAULT_CATALOG_NAME + validate_default_catalog(default_catalog=result[0])
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
tests/model_registry/conftest.py(0 hunks)tests/model_registry/model_catalog/test_default_model_catalog.py(4 hunks)tests/model_registry/rbac/conftest.py(0 hunks)tests/model_registry/utils.py(0 hunks)
💤 Files with no reviewable changes (3)
- tests/model_registry/conftest.py
- tests/model_registry/rbac/conftest.py
- tests/model_registry/utils.py
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: lugi0
PR: opendatahub-io/opendatahub-tests#487
File: tests/model_registry/async_job/constants.py:23-31
Timestamp: 2025-08-08T15:58:03.524Z
Learning: In opendatahub-io/opendatahub-tests, for tests under tests/model_registry/async_job (e.g., constants.py and related fixtures), runs start from a clean, known Model Registry state. Therefore, using static MODEL_ID, MODEL_VERSION_ID, and MODEL_ARTIFACT_ID values in MODEL_SYNC_CONFIG is intentional and acceptable; dynamic ID injection is not required for these async job tests (per guidance from user lugi0).
Learnt from: lugi0
PR: opendatahub-io/opendatahub-tests#446
File: tests/model_registry/conftest.py:733-770
Timestamp: 2025-07-17T15:42:23.880Z
Learning: In tests/model_registry/conftest.py, the model_registry_instance_1 and model_registry_instance_2 fixtures do not need explicit database dependency fixtures (like db_deployment_1, db_secret_1, etc.) in their function signatures. Pytest's dependency injection automatically handles the fixture dependencies when they reference db_name_1 and db_name_2 parameters. This is the correct pattern for these Model Registry instance fixtures.
📚 Learning: 2025-08-08T15:58:03.524Z
Learnt from: lugi0
PR: opendatahub-io/opendatahub-tests#487
File: tests/model_registry/async_job/constants.py:23-31
Timestamp: 2025-08-08T15:58:03.524Z
Learning: In opendatahub-io/opendatahub-tests, for tests under tests/model_registry/async_job (e.g., constants.py and related fixtures), runs start from a clean, known Model Registry state. Therefore, using static MODEL_ID, MODEL_VERSION_ID, and MODEL_ARTIFACT_ID values in MODEL_SYNC_CONFIG is intentional and acceptable; dynamic ID injection is not required for these async job tests (per guidance from user lugi0).
Applied to files:
tests/model_registry/model_catalog/test_default_model_catalog.py
📚 Learning: 2025-08-21T19:08:14.982Z
Learnt from: dbasunag
PR: opendatahub-io/opendatahub-tests#527
File: tests/model_registry/rbac/conftest.py:358-359
Timestamp: 2025-08-21T19:08:14.982Z
Learning: In tests/model_registry/rbac/conftest.py, the model catalog configmap only exists in one specific namespace (py_config["model_registry_namespace"]) regardless of where model registry instances are deployed, making it a shared resource that serves all model registry instances across namespaces.
Applied to files:
tests/model_registry/model_catalog/test_default_model_catalog.py
🔇 Additional comments (3)
tests/model_registry/model_catalog/test_default_model_catalog.py (3)
13-13: Good move: centralize “default catalog” expectations via constants.Eliminates magic strings/IDs in tests and keeps expectations aligned across suites.
29-37: Ensurepost_upgrademarker is registered and used in CI selection.Register the marker in pytest.ini to avoid PytestUnknownMarkWarning and wire it into the upgrade job select expression.
If missing, add:
+# pytest.ini +[pytest] +markers = + post_upgrade: Run only after cluster upgrade completes.
60-66: Same as above forpost_upgradeon parametrized resource test.Confirm the marker is declared and that your CI runs
-m post_upgradein the upgrade stage.
|
The following are automatically added/executed:
Available user actions:
Supported labels{'/hold', '/cherry-pick', '/lgtm', '/build-push-pr-image', '/verified', '/wip'} |
|
Status of building tag latest: success. |
* on rebase clean commented-by- labels * Add default MC validation tests to upgrade
Description
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit