Fail fast when no tests are selected after collection

.claude/CLAUDE.md

@@ -0,0 +1,43 @@
+# System-Tests - Claude AI Configuration
+
+## Important: Shared Rules with Cursor
+
+**All AI assistant rules are maintained in the `.cursor/rules/` directory.**
+
+## Always Applied Rules
+
+Claude MUST read and follow all rules from these files and follow these rules in EVERY interaction:
+
+1. **`.cursor/rules/general-behavior.mdc`** - AI behaviour: communication style, documentation references, Slack support
+2. **`.cursor/rules/system-tests-overview.mdc`** - Project overview, main concepts, terminology
+3. **`.cursor/rules/repository-structure.mdc`** - Repository structure, test class conventions
+4. **`.cursor/rules/fine-tuning-guidance.mdc`** - Documentation navigation, scenario discovery
+5. **`.cursor/rules/code-format-standards.mdc`** - Code formatting requirements (shellcheck, mypy, YAML)
+6. **`.cursor/rules/aws-ssi-testing.mdc`** - AWS SSI testing guidelines
+7. **`.cursor/rules/end-to-end-testing.mdc`** - End-to-end testing guidelines
+8. **`.cursor/rules/k8s-ssi.mdc`** - Kubernetes library injection testing
+9. **`.cursor/rules/test-activation.mdc`** - Test activation/deactivation rules
+10. **`.cursor/rules/doc.mdc`** - Rules for editing the documentation
+11. **`.cursor/rules/devtools.mdc`** - Developer tools: MCP, GitHub (gh), GitLab (glab) usage
+
+## Manual Rules (Apply Only When Explicitly Requested)
+
+12. **`.cursor/rules/java-endpoint-prompt.mdc`** - Java endpoint creation prompts
+
+## Pull request review guidelines
+
+13. **`.cursor/rules/pr-review.mdc`** - Pull Request review guidelines and checklist
+
+---
+
+## Quick Reference
+
+- **Project**: System tests for Datadog tracer libraries (Java, Node.js, Python, PHP, Ruby, C++, .NET, Go, Rust)
+- **Framework**: pytest
+- **Main Scenarios**: end-to-end, parametric, SSI, Kubernetes
+- **Scenario Source**: `utils/_context/_scenarios/__init__.py`
+- **Support**: #apm-shared-testing Slack channel
+
+---
+
+**Note**: This `CLAUDE.md` is a pointer to the actual rules. All detailed rules and guidelines are in the `.cursor/rules/*.mdc` files. Read those files directly for complete context.

.claude/settings.json

@@ -0,0 +1,33 @@
+{
+  "env": {
+    "OTEL_RESOURCE_ATTRIBUTES": "repo.owner=DataDog,repo.name=system-tests"
+  },
+  "defaultMode": "acceptEdits",
+  "enabledMcpjsonServers": [
+    "datadog"
+  ],
+  "enableAllProjectMcpServers": true,
+  "extraKnownMarketplaces": {
+    "datadog-claude-plugins": {
+      "source": {
+        "source": "github",
+        "repo": "DataDog/claude-marketplace"
+      }
+    }
+  },
+  "enabledPlugins": {
+    "marketplace-auto-update@datadog-claude-plugins": true,
+    "dd@datadog-claude-plugins": true
+  },
+  "permissions": {
+    "deny": [
+      "Skill(dd:conductor *)",
+      "Skill(dd:trebuchet *)",
+      "Skill(dd:render-helm *)",
+      "Skill(dd:deploy-yaml-local-dev *)",
+      "Skill(dd:integrate *)",
+      "Skill(dd:live-test-api *)",
+      "Skill(dd:debug-ddci-request *)"
+    ]
+  }
+}

.cursor/mcp.json

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "datadog": {
+      "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=software-delivery",
+      "headers": {}
+    }
+  }
+}

.cursor/rules/aws-ssi-testing.mdc

@@ -0,0 +1,20 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# AWS SSI
+
+* The basic documentation about the AWS SSI tests is in the document @docs/scenarios/onboarding.md. This document contains a good overview of the AWS SSI tests, the requirements ("Prerequisites" section) to run ("Run the tests" section), and how to operate/develop with them. Use it to answer questions about the AWS SSI tests.
+* Vagrant requirements are only if you want to run the tests using Vagrant instead of AWS. Vagrant is discontinued in system-tests.
+* The aws_onboarding_wizard.sh script is used to run the AWS onboarding tests. It doesn't need any parameters. You can also run the AWS tests manually; you MUST check the doc @docs/scenarios/onboarding.md in the section 'Run the scenario manually'. ALWAYS mention 'aws-vault' as an example. How to run the AWS SSI tests manually: ALWAYS describe the mandatory parameters as they are described in the documentation (--vm-library, --vm-env, --vm-weblog, --vm-provider, --vm-only). Do not make reference to other parameters that do not appear in the onboarding documentation.
+* To register a new virtual machine, please ask the user for the name and other required fields to register a new virtual machine in system-tests. Be strict with the fields that already exist in the file [virtual_machines.json](mdc:utils/virtual_machine/virtual_machines.json), NEVER invent new fields. For example, the field `os_version' it doesn't exists. NEVER ask or show to the user fields that they don't exist. you MUST validate all updates of the virtual_machines.json using the json schema: [virtual machines json schema](mdc:utils/virtual_machine/virtual_machines.jsschema)](utils/build/virtual_machine/weblogs/weblog_provision_schema.yml), this scheme validation should be done by you, never by the user.
+* After registering a new virtual machine, you ALWAYS must define which weblogs are compatible with this new VM. Help the user to do this task by executing the script [vm_compatibility_checker](mdc:utils/scripts/ssi_wizards/tools/aws_ssi_registration.py) with the parameter --vm and the new VM name as value to define the compatibility between the virtual machines and the weblogs.
+* To create or update a weblog provision for AWS SSI tests, ALWAYS verify that you are using the correct format, checking the section "Weblog Provision Structure" from the document [onboarding_provision_section](mdc:docs/scenarios/onboarding_provision_section.md) and the document [onboarding](mdc:docs/scenarios/onboarding.md) and the existing provision files under 'utils/build/virtual_machine/weblogs' folder. You MUST ALWAYS validate all updates or new code for a weblog aws ssi provision using the [weblog provision yaml schema](mdc:utils/build/virtual_machine/weblogs/weblog_provision_schema.yml), this scheme validation should be done by you, never by the user.
+* After creating a new weblog for AWS SSI tests, you ALWAYS must define in which scenarios it is going to run and which virtual machines are compatible with this new weblog. Help the user to do this task by executing the script [weblog_registration](mdc:utils/scripts/ssi_wizards/tools/aws_ssi_registration.py) with the parameter --weblog and the new weblog name as value.
+* AWS SSI scenario creation/update ALWAYS verify the scenario is declared in the utils/_context/_scenarios/__init__.py and the "vm_provision" field matched provision folder name. Use the class "InstallerAutoInjectionScenario" to define new scenarios. The scenario provision file is in (utils/build/virtual_machine/provisions/[name]/provision.yml). All new or update scenario provision ALWAYS MUST be validated using the section "Scenario Provision Structure" from the document docs/scenarios/onboarding_provision_section.md and the existing scenario provisions under the folder utils/build/virtual_machine/provisions. You MUST ALWAYS validate all updates or new code for a scenario provision on aws ssi using the [scenario provision yaml schema](mdc:utils/build/virtual_machine/provisions/scenario_provision_schema.yml)](utils/build/virtual_machine/weblogs/weblog_provision_schema.yml), this scheme validation should be done by you, never by the user.
+* After creating a new scenario for AWS SSI tests, you ALWAYS must define which weblogs are compatible with this new scenario. Help the user to do this task by executing the script [scenario_registration](mdc:utils/scripts/ssi_wizards/tools/aws_ssi_registration.py) with the parameter --scenario and the new scenario name as value.
+  [aws ssi json](mdc:utils/scripts/ci_orchestrators/aws_ssi.json) is the file that configures the compatibility between the virtual machines and the weblogs and which weblogs will run on each scenario.
+* For provision files in system-tests AWS SSI scenarios, check both the scenario provision (in utils/build/virtual_machine/provisions/[name]/provision.yml) and weblog provision (in utils/build/virtual_machine/weblogs/[lang]/provision_[weblog].yml). These YAML files define environment variables, installation steps, and commands to run by OS type. Each provision step can include remote commands, local commands, and file copying operations with OS-specific targeting through os_type, os_distro, and os_cpu keys. Remember that the tested_components section must return a valid JSON with component versions.
+* When analyzing results or troubleshooting AWS SSI tests, always consult `docs/scenarios/onboarding.md` (sections 'How to debug your environment and tests results' and 'Troubleshooting') as the authoritative reference to interpret the tests’ standard output and the possible failures. 
+* When analyzing results or troubleshooting AWS SSI tests, always consult `docs/scenarios/onboarding.md` (sections 'How to debug your environment and tests results' and 'Troubleshooting') try to mention the logs file that the user should check depending the failure type.

.cursor/rules/code-format-standards.mdc

@@ -0,0 +1,11 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Code format
+
+* All shell/bash scripts must be compatible with shellcheck. All shell/bash scripts you create or modify must pass shellcheck without errors or warnings.
+* Follow Python type annotation best practices that are compatible with mypy strict checking, using Python 3.12 standards as defined in pyproject.toml. Always provide explicit type annotations for all function arguments and return values. For collections, use precise types (e.g., list[str], dict[str, int]). If a value can be None, always use Optional[...] explicitly. Do not rely on implicit Optional types (e.g., avoid using x: int = None—instead, use x: Optional[int] = None). Do not omit type annotations, and do not use untyped or partially typed collections.
+* Always run [format](mdc:format.sh) before committing changes to ensure code follows the project's style guidelines,  including proper Path usage instead of os.path, no unused variables, complete type annotations, and efficient code patterns that satisfy mypy and ruff checks. if the format.sh script fails, try to fix the format mistakes.
+* All YAML files you create or modify must pass both yamllint and yamlfmt checks before being committed.

.cursor/rules/devtools.mdc

@@ -0,0 +1,27 @@
+---
+description: Rules for interacting with developer tools and external ci services
+globs: 
+alwaysApply: true
+---
+# Developer Tools
+
+## MCP Tools
+
+* Datadog MCP defaults: When using Datadog MCP tools (CI pipelines, tests, flaky tests, coverage, PR insights), default to the repository `github.com/DataDog/system-tests` (or `https://github.com/DataDog/system-tests` for PR-related tools) unless the user specifies a different repository. Use the current git branch and latest commit SHA as context when relevant.
+
+## GitHub Tools
+
+- When interacting with GitHub (github.com), ALWAYS use `gh` on the command line.
+- If `gh` CLI is not installed or there are authentication or configuration problems, check the document: [AI Tools Integration Guide - GitHub CLI](mdc:docs/ai/ai-tools-integration-guide.md#github-cli-gh)
+
+## GitLab Tools
+
+- When interacting with GitLab (gitlab.ddbuild.io), ALWAYS use `glab` on the command line.
+- If `glab` CLI is not installed or there are authentication or configuration problems, check the document: [AI Tools Integration Guide - GitLab CLI](mdc:docs/ai/ai-tools-integration-guide.md#gitlab-cli-glab)
+
+
+## Handling the Pull Request and CI
+
+- To create and monitor PR data, use the gh client (GitHub Tools).
+- If the request relates to CI status for a branch or PR, MUST ALWAYS try the Datadog MCP first.
+- Use local GitLab/GitHub tools as a fallback/support for the Datadog MCP when interacting with GitLab/GitHub CI.

.cursor/rules/doc.mdc

@@ -0,0 +1,28 @@
+---
+description: Rules to edit the documentation
+globs: docs/*
+alwaysApply: true
+---
+# Editing the documenation
+
+## Key Documentation
+
+- @docs/glossary.md: Technical definitions to use
+
+## Rules
+
+### Links
+
+Repetitions should be avoided. Prefer using links to other pages of the documentation
+instead of repeating information.
+
+### Outdated information
+
+When you find a contradiction in the documentation or when the documentation contradicts
+know behavior of the system signal it to the user and propose a fix.
+
+### Glossary
+
+When appropriate use the words from the glossary. You should avoid using similar 
+words to avoid ambiguities. When you use many words from the glossary you can
+add a link to the glossary to help the reader.