Merge branch 'main' into smoke-refactor

Author: mwaykole

.github/pull_request_template.md

@@ -1,3 +1,5 @@
+# Pull Request
+
 ## Summary
 
 <!-- Brief description of changes and why they are needed -->

.github/workflows/workflow-review.yml

@@ -20,16 +20,29 @@ jobs:
 
     steps:
       - name: save the pr information
+        env:
+          COMMENT_BODY: ${{ github.event.comment.body }}
+          REVIEW_BODY: ${{ github.event.review.body }}
+          USER_LOGIN: ${{ github.event.sender.login }}
         run: |
-            printf '{
-              "pr_num": "${{ github.event.pull_request.number || github.event.issue.number }}",
-              "event_action": "${{ github.event.action }}",
-              "review_state": "${{ github.event.review.state }}",
-              "event_name": "${{ github.event_name }}",
-              "comment_body": "${{ github.event.comment.body }}",
-              "review_comment_body": "${{ github.event.review.body }}",
-              "user_login": "${{ github.event.sender.login }}",
-              "action": "add-remove-labels"
+          jq -n \
+            --arg pr_num "${{ github.event.pull_request.number || github.event.issue.number }}" \
+            --arg event_action "${{ github.event.action }}" \
+            --arg review_state "${{ github.event.review.state }}" \
+            --arg event_name "${{ github.event_name }}" \
+            --arg comment_body "$COMMENT_BODY" \
+            --arg review_comment_body "$REVIEW_BODY" \
+            --arg user_login "$USER_LOGIN" \
+            --arg action "add-remove-labels" \
+            '{
+              pr_num: $pr_num,
+              event_action: $event_action,
+              review_state: $review_state,
+              event_name: $event_name,
+              comment_body: $comment_body,
+              review_comment_body: $review_comment_body,
+              user_login: $user_login,
+              action: $action
             }' >> context.json
       - uses: actions/upload-artifact@v6
         with:

.markdownlint.json

@@ -0,0 +1,13 @@
+{
+  "default": true,
+  "MD003": { "style": "atx" },
+  "MD004": false,
+  "MD007": false,
+  "MD010": {"code_blocks": false},
+  "MD013": false,
+  "MD026": {"punctuation": ".,;!。，；：！"},
+  "MD029": false,
+  "MD051": false,
+  "no-hard-tabs": false,
+  "whitespace": false
+}

.pre-commit-config.yaml

@@ -71,10 +71,23 @@ repos:
           - --types=build,ci,chore,docs,feat,fix,perf,refactor,revert,style,test
           - --subject-min-length=10
           - --subject-max-length=80
+
   - repo: local
     hooks:
         - id: check-prohibited-patterns
           name: Check for prohibited code patterns
           entry: python scripts/check_incorrect_wrapper_usage.py
           language: python
           pass_filenames: false
+
+  - repo: https://github.com/rhysd/actionlint
+    rev: v1.7.4
+    hooks:
+      - id: actionlint
+
+  - repo: https://github.com/DavidAnson/markdownlint-cli2
+    rev: v0.21.0
+    hooks:
+      - id: markdownlint-cli2
+        args:
+          - --fix

AGENTS.md

@@ -8,6 +8,7 @@ You are an expert QE engineer writing maintainable pytest tests that other engin
 ## Commands
 
 ### Validation (run before committing)
+
 ```bash
 # Run all pre-commit checks
 pre-commit run --all-files
@@ -17,6 +18,7 @@ tox
 ```
 
 ### Test Execution
+
 ```bash
 # Collect tests without running (verify structure)
 uv run pytest --collect-only
@@ -45,17 +47,20 @@ utilities/                # Shared utility functions
 ## Essential Patterns
 
 ### Tests
+
 - Every test MUST have a docstring explaining what it tests (see `tests/cluster_health/test_cluster_health.py`)
 - Apply relevant markers from `pytest.ini`: tier (`smoke`, `sanity`, `tier1`, `tier2`), component (`model_serving`, `model_registry`, `llama_stack`), infrastructure (`gpu`, `parallel`, `slow`)
 - Use Given-When-Then format in docstrings for behavioral clarity
 
 ### Fixtures
+
 - Fixture names MUST be nouns: `storage_secret` not `create_secret`
 - Use context managers for resource lifecycle (see `tests/conftest.py:544-550` for pattern)
 - Fixtures do one thing only—compose them rather than nesting
 - Use narrowest scope that meets the need: function > class > module > session
 
 ### Kubernetes Resources
+
 - Use [openshift-python-wrapper](https://github.com/RedHatQE/openshift-python-wrapper) for all K8s API calls
 - Resource lifecycle MUST use context managers to ensure cleanup
 - Use `oc` CLI only when wrapper is not relevant (e.g., must-gather)
@@ -70,19 +75,22 @@ utilities/                # Shared utility functions
 ## Boundaries
 
 ### ✅ Always
+
 - Follow existing patterns before introducing new approaches
 - Add type annotations (mypy strict enforced)
 - Write Google-format docstrings for tests and fixtures
 - Run `pre-commit run --all-files` before suggesting changes
 
 ### ⚠️ Ask First
+
 - Adding new dependencies to `pyproject.toml`
 - Creating new `conftest.py` files
 - Moving fixtures to shared locations
 - Adding new markers to `pytest.ini`
 - Modifying session-scoped fixtures
 
 ### 🚫 Never
+
 - Remove or modify existing tests without explicit request
 - Add code that isn't immediately used (YAGNI)
 - Log secrets, tokens, or credentials
@@ -92,6 +100,7 @@ utilities/                # Shared utility functions
 ## Documentation Reference
 
 Consult these for detailed guidance:
+
 - [Constitution](./CONSTITUTION.md) - Non-negotiable principles (supersedes all other docs)
 - [Developer Guide](./docs/DEVELOPER_GUIDE.md) - Contribution workflow, fixture examples
 - [Style Guide](./docs/STYLE_GUIDE.md) - Naming, typing, docstrings

CONSTITUTION.md

@@ -156,6 +156,7 @@ No versioning policy is enforced.
 ### Guidance Reference
 
 For development runtime guidance, consult:
+
 - [AGENTS.md](./AGENTS.md) for AI assistant instructions
 - [DEVELOPER_GUIDE.md](./docs/DEVELOPER_GUIDE.md) for contribution details
 - [STYLE_GUIDE.md](./docs/STYLE_GUIDE.md) for code style

README.md

@@ -3,17 +3,20 @@
 This repository contains ODH / Red Hat Openshift AI (RHOAI) tests.  
 The tests are written in Python and use [pytest](https://docs.pytest.org/en/stable/) as a test framework.
 
-
 ## Getting started
+
 Please follow the [Getting Started Guide](docs/GETTING_STARTED.md) on how to run the tests.
 
+
 ## Example of upgrade testing
+
 Please follow the [Upgrade Guide](docs/UPGRADE.md) on how to run the upgrade tests.
 
 
 ## Contribute to opendatahub-tests
-Please follow the [Contributing Guide](docs/CONTRIBUTING.md) and the [Developer guide](docs/DEVELOPER_GUIDE.md)
 
+Please follow the [Contributing Guide](docs/CONTRIBUTING.md) and the [Developer guide](docs/DEVELOPER_GUIDE.md)
 
 ## GitHub workflows
+
 Please follow the [GitHub workflows Guide](docs/GITHUB_WORKFLOWS.md) for more information.

VSCODE_CONFIG.md

@@ -13,7 +13,7 @@ to `"mypy-type-checker.args" = ["--config-file=pyproject.toml"]`.
 If you use Visual Studio Code and want to debug your test execution with its "Run and Debug" feature, you'll want to use
 a `launch.json` file similar to this one:
 
-```
+```json
 {
     // Use IntelliSense to learn about possible attributes.
     // Hover to view descriptions of existing attributes.

docs/CONTRIBUTING.md

@@ -15,4 +15,5 @@ If you open a pull request to fix the problem, an issue will ba automatically cr
 If a related issue doesn't exist, you can open a new issue using a relevant [issue form](https://github.com/opendatahub-io/opendatahub-tests/issues/new/choose).
 
 ## Pull requests
+
 Follow the guidelines in [Developer guide](DEVELOPER_GUIDE.md)

docs/DEVELOPER_GUIDE.md

@@ -1,6 +1,7 @@
 # Project Structure
 
 The project is structured as follows:
+
 - [tests](../tests): Base directory for pytest tests
   - Each component has its own directory
   - Each feature has its own directory
@@ -12,11 +13,12 @@ The project is structured as follows:
 - [py_config](../tests/global_config.py) contains tests-specific configuration which can be controlled from the command line.  
 Please refer to [pytest-testconfig](https://github.com/wojole/pytest-testconfig) for more information.
 
+## Contribution
 
-# Contribution
 To contribute code to the project:
 
 ## Pull requests
+
 - Fork the project and work on your forked repository
 - Before submitting a new pull request:
   - Make sure you follow the [Style guide](STYLE_GUIDE.md)
@@ -40,11 +42,12 @@ To contribute code to the project:
   - All CI checks must pass.
 
 ## Branching strategy
-The project follows RHOAI [release lifecyle strategy](https://access.redhat.com/support/policy/updates/rhoai-sm/lifecycle).  
-If needed, once your PR is merged to `main`, cherry-pick your PR to the relevant branch(es).
 
+The project follows RHOAI [release lifecycle strategy](https://access.redhat.com/support/policy/updates/rhoai-sm/lifecycle).  
+If needed, once your PR is merged to `main`, cherry-pick your PR to the relevant branch(es).
 
 ## Python
+
 - Reduce duplicate code, before writing new function search for it, probably someone already wrote it or one that should serve your needs.
   - The project uses external packages that may already have a functionality that does what you need.
 - When using a variable more than once save it and reuse.
@@ -60,8 +63,8 @@ If needed, once your PR is merged to `main`, cherry-pick your PR to the relevant
 - Log enough to make you debug and understand the flow easy, but do not spam the log with unuseful info.  
 Error logs should be detailed with what failed, status and so on.
 
-
 ## Interacting with Kubernetes/OpenShift APIs
+
 The project utilizes [openshift-python-wrapper](https://github.com/RedHatQE/openshift-python-wrapper).
 Please refer to the [documentation](https://github.com/RedHatQE/openshift-python-wrapper/blob/main/README.md)  
 and the [examples](https://github.com/RedHatQE/openshift-python-wrapper/tree/main/examples) for more information.
@@ -72,14 +75,14 @@ create a PR against wrapper. Calls to cluster resources from tests, utils and fi
 openshift-python-wrapper resource or oc command
 (when wrapper resource is not relevant. e.g. must-gather generation)
 
-
 ## Conftest
+
 - Top level [conftest.py](../conftest.py) contains pytest native fixtures.
 - General tests [conftest.py](../tests/conftest.py) contains fixtures that are used in multiple tests by multiple teams.
 - If needed, create new `conftest.py` files in the relevant directories.
 
-
 ## Fixtures
+
 - Ordering: Always call pytest native fixtures first, then session-scoped fixtures and then any other fixtures.
 - Fixtures should handle setup (and the teardown, if needed) needed for the test(s), including the creation of resources for example.
 - Fixtures should do one thing only.  
@@ -136,21 +139,21 @@ def storage_secret(request):
 secret = Secret(name=request.param["name"], model_dir=request.param["model-dir"])
 ```
 
-
 ## Tests
+
 - Pytest reports failures in fixtures as FAILED
 - Each test should have a clear purpose and should be easy to understand.
 - Each test should verify a single aspect of the product.
 - Preferably, each test should be independent of other tests.
-- When there's a dependency between tests use pytest dependency plugin to mark the relevant hierarchy between tests (https://github.com/RKrahl/pytest-dependency)
+- When there's a dependency between tests use pytest dependency plugin to mark the relevant hierarchy between tests ([pytest-dependency](https://github.com/RKrahl/pytest-dependency))
 - When adding a new test, apply relevant marker(s) which may apply.  
 Check [pytest.ini](../pytest.ini) for available markers; additional markers can always be added when needed.
 - Classes are good to group related tests together, for example when they share a fixture.  
 You should NOT group unrelated tests in one class (because it is misleading the reader).
-- All the tests should be properly documented. Every test (or test class), should have a docstring explaning what the test does so that anyone (engineers from other components, managers, PMs, or non-technical users) can have a basic understanding of what the code is trying to test without having to dive into the technical details of related functions or fixtures.
-
+- All the tests should be properly documented. Every test (or test class), should have a docstring explaining what the test does so that anyone (engineers from other components, managers, PMs, or non-technical users) can have a basic understanding of what the code is trying to test without having to dive into the technical details of related functions or fixtures.
 
 ## Check the code
+
 ### pre-commit
 
 When submitting a pull request, make sure to fill all the required, relevant fields for your PR.  
@@ -169,6 +172,7 @@ pre-commit run --all-files
 ```
 
 ### tox
+
 CI uses [tox](https://tox.readthedocs.io/en/latest/) and will run the code under tox.ini  
 
 Run tox:
@@ -178,9 +182,12 @@ tox
 ```
 
 ## Adding new runtime
-To add a new runtime, you need to:  
+
+To add a new runtime, you need to:
+
 1. Add a new file under [manifests](../utilities/manifests) directory.
 2. Add `<runtime>_INFERENCE_CONFIG` dict with:
+
 ```code
     "support_multi_default_queries": True|False,  # Optioanl, if set to True, `default_query_model` should contains a dict with corresponding inference_type
     "default_query_model": {
@@ -199,12 +206,16 @@ To add a new runtime, you need to:
             },
         },
 ```
+
 3. See [caikit_standalone](../utilities/manifests/caikit_standalone.py) for an example
 
 ## AI Usage
+
 If using AI tooling to assist you in the process of writing or reviewing code:
+
 1. Understand what you are doing --as a developer, you are ultimately responsible for the code. Always assume the code produced by the AI tools is unsafe and incorrect, and always double-check it.
 2. We support [AGENTS.md](../AGENTS.md), an [open format](https://agents.md/) for guiding coding agents. If you use any proprietary tool that does not support `AGENTS.md` (e.g. Claude Code, Qwen Code, Gemini Code), you can create a symlink:
+
 ```bash
 ln -s AGENTS.md CLAUDE.md
 ```