|
1 | 1 | # Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
|
2 | 2 | # SPDX-License-Identifier: BSD-3-Clause-Clear
|
3 | 3 |
|
4 |
| -# Contributing to the Shell Scripts Repository |
| 4 | +# 🛠️ Contributing to qcom-linux-testkit |
5 | 5 |
|
6 |
| -Welcome! This repository contains hardware validation shell scripts for Qualcomm embedded robotic platform boards running Linux systems. These scripts follow POSIX standards for maximum portability and integration into CI tools like LAVA. |
| 6 | +Thank you for considering contributing to the **qcom-linux-testkit** project! Your contributions help improve the quality and functionality of our test suite. Please follow the guidelines below to ensure a smooth contribution process. |
7 | 7 |
|
8 |
| -## Directory Structure |
| 8 | +--- |
9 | 9 |
|
10 |
| -- `Runner/`: Root test harness |
11 |
| -- `Runner/utils/`: Shared libraries like `functestlib.sh` |
12 |
| -- `Runner/init_env`: Common environment setup |
13 |
| -- `Runner/suites/`: Functional test suites organized per feature |
| 10 | +## 📋 Contribution Checklist |
14 | 11 |
|
15 |
| -## Getting Started |
| 12 | +Before submitting a PR, please ensure the following: |
16 | 13 |
|
17 |
| -1. Clone the repository: |
| 14 | +- [ ] **Branching**: Create your feature or fix branch from the latest `main` branch. |
| 15 | +- [ ] **Descriptive Commits**: Write clear and concise commit messages. |
| 16 | +- [ ] **ShellCheck Compliance**: Run ShellCheck on all modified shell scripts and address any warnings or errors. |
| 17 | +- [ ] **Functionality**: Verify that your changes do not break existing functionality. |
| 18 | +- [ ] **Documentation**: Update or add documentation as necessary. |
| 19 | +- [ ] **Testing**: Add or update tests to cover your changes, if applicable. |
| 20 | + |
| 21 | +--- |
| 22 | + |
| 23 | +## 🧪 Running ShellCheck |
| 24 | + |
| 25 | +We use [ShellCheck](https://www.shellcheck.net/) to analyze shell scripts for common mistakes and potential issues. |
| 26 | + |
| 27 | +### Installation |
| 28 | + |
| 29 | +You can install ShellCheck using your package manager: |
| 30 | + |
| 31 | +- **macOS**: `brew install shellcheck` |
| 32 | +- **Ubuntu/Debian**: `sudo apt-get install shellcheck` |
| 33 | +- **Fedora**: `sudo dnf install ShellCheck` |
| 34 | +- **Arch Linux**: `sudo pacman -S shellcheck` |
| 35 | + |
| 36 | +### Usage |
| 37 | + |
| 38 | +To analyze a script: |
| 39 | + |
| 40 | +```bash |
| 41 | +shellcheck path/to/your_script.sh |
| 42 | +``` |
| 43 | + |
| 44 | +Address all warnings and errors before submitting your PR. If you need to disable a specific ShellCheck warning, use: |
| 45 | + |
| 46 | +```sh |
| 47 | +# shellcheck disable=SC1090 |
| 48 | +``` |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## 📂 Test Suite Structure & Pseudocode Guidelines |
| 53 | + |
| 54 | +Each test suite must follow the standard structure shown below and include a `run.sh` script that: |
| 55 | + |
| 56 | +- Sources `init_env` and `functestlib.sh` |
| 57 | +- Sets `TESTNAME` |
| 58 | +- Finds the test directory dynamically |
| 59 | +- Logs results using `log_pass`, `log_fail`, and outputs a `.res` file |
| 60 | + |
| 61 | +### Directory Structure |
| 62 | + |
| 63 | +``` |
| 64 | +Runner/ |
| 65 | +├── suites/ |
| 66 | +│ └── Kernel/ |
| 67 | +│ └── FunctionalArea/ |
| 68 | +│ └── baseport/ |
| 69 | +│ └── Foo_Validation/ |
| 70 | +│ ├── run.sh |
| 71 | +│ └── enabled_tests.list (optional) |
| 72 | +├── utils/ |
| 73 | +│ ├── init_env |
| 74 | +│ └── functestlib.sh |
| 75 | +``` |
| 76 | + |
| 77 | +### Pseudo `run.sh` Template |
| 78 | + |
| 79 | +```sh |
| 80 | +#!/bin/sh |
| 81 | +# SPDX-License-Identifier: BSD-3-Clause-Clear |
| 82 | + |
| 83 | +#Source init_env and functestlib.sh |
| 84 | +SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" |
| 85 | +INIT_ENV="" |
| 86 | +SEARCH="$SCRIPT_DIR" |
| 87 | +while [ "$SEARCH" != "/" ]; do |
| 88 | + if [ -f "$SEARCH/init_env" ]; then |
| 89 | + INIT_ENV="$SEARCH/init_env" |
| 90 | + break |
| 91 | + fi |
| 92 | + SEARCH=$(dirname "$SEARCH") |
| 93 | +done |
| 94 | + |
| 95 | +if [ -z "$INIT_ENV" ]; then |
| 96 | + echo "[ERROR] Could not find init_env (starting at $SCRIPT_DIR)" >&2 |
| 97 | + exit 1 |
| 98 | +fi |
| 99 | + |
| 100 | +# Only source if not already loaded (idempotent) |
| 101 | +if [ -z "$__INIT_ENV_LOADED" ]; then |
| 102 | + # shellcheck disable=SC1090 |
| 103 | + . "$INIT_ENV" |
| 104 | +fi |
| 105 | +# Always source functestlib.sh, using $TOOLS exported by init_env |
| 106 | +# shellcheck disable=SC1090,SC1091 |
| 107 | +. "$TOOLS/functestlib.sh" |
| 108 | + |
| 109 | +TESTNAME="Foo_Validation" |
| 110 | +test_path=$(find_test_case_by_name "$TESTNAME") || { |
| 111 | + log_fail "$TESTNAME : Test directory not found." |
| 112 | + echo "FAIL $TESTNAME" > "./$TESTNAME.res" |
| 113 | + exit 1 |
| 114 | +} |
| 115 | + |
| 116 | +cd "$test_path" || exit 1 |
| 117 | +res_file="./$TESTNAME.res" |
| 118 | +rm -f "$res_file" |
| 119 | + |
| 120 | +log_info "Starting $TESTNAME" |
| 121 | + |
| 122 | +# Run test logic |
| 123 | +if run_some_check_or_command; then |
| 124 | + log_pass "$TESTNAME: passed" |
| 125 | + echo "PASS $TESTNAME" > "$res_file" |
| 126 | +else |
| 127 | + log_fail "$TESTNAME: failed" |
| 128 | + echo "FAIL $TESTNAME" > "$res_file" |
| 129 | +fi |
| 130 | +``` |
| 131 | + |
| 132 | +### `.res` File Requirements |
| 133 | + |
| 134 | +Each `run.sh` **must generate** a `.res` file in the same directory: |
| 135 | + |
| 136 | +- **File Name**: `<TESTNAME>.res` |
| 137 | +- **Content**: |
| 138 | + - `PASS <TESTNAME>` on success |
| 139 | + - `FAIL <TESTNAME>` on failure |
| 140 | + - `SKIP <TESTNAME>` if not applicable |
| 141 | + |
| 142 | +This is essential for CI/CD to parse test outcomes. |
| 143 | + |
| 144 | +### Logging Conventions |
| 145 | + |
| 146 | +Use logging functions from `functestlib.sh`: |
| 147 | +```sh |
| 148 | +log_info "Preparing test" |
| 149 | +log_pass "Test completed successfully" |
| 150 | +log_fail "Test failed" |
| 151 | +log_error "Setup error" |
| 152 | +log_skip "Skipped due to condition" |
| 153 | +``` |
| 154 | + |
| 155 | +--- |
| 156 | + |
| 157 | +## 📄 Licensing |
| 158 | + |
| 159 | +Ensure that all new files include the appropriate license header: |
| 160 | + |
| 161 | +```sh |
| 162 | +#!/bin/sh |
| 163 | +# SPDX-License-Identifier: BSD-3-Clause-Clear |
| 164 | +``` |
| 165 | + |
| 166 | +--- |
| 167 | + |
| 168 | +## 📬 Submitting a Pull Request |
| 169 | + |
| 170 | +1. **Fork** the repository and create your feature branch: |
18 | 171 | ```bash
|
19 |
| - git clone https://github.com/qualcomm-linux/qcom-linux-testkit.git |
| 172 | + git checkout -b feature/your-feature-name |
20 | 173 | ```
|
21 | 174 |
|
22 |
| -2. Run test suites using: |
| 175 | +2. **Commit** your changes with clear messages: |
23 | 176 | ```bash
|
24 |
| - ./Runner/run-test.sh |
| 177 | + git commit -m "feat: add new feature" |
25 | 178 | ```
|
26 | 179 |
|
27 |
| -3. Ensure `init_env` and utilities are sourced using relative paths: |
| 180 | +3. **Push** to your fork: |
28 | 181 | ```bash
|
29 |
| - . "$(dirname "$0")/../../init_env" |
30 |
| - . "$(dirname "$0")/../../utils/functestlib.sh" |
| 182 | + git push origin feature/your-feature-name |
31 | 183 | ```
|
32 | 184 |
|
33 |
| -## Style Guidelines |
| 185 | +4. **Open a Pull Request**: Navigate to the original repository and open a PR from your forked branch. |
34 | 186 |
|
35 |
| -- Shell scripts must be POSIX-compliant (`#!/bin/sh`) |
36 |
| -- Avoid Bash-specific syntax |
37 |
| -- Validate using `shellcheck -x` |
38 |
| -- Use consistent format: colored output, logging, `PASS/FAIL` status |
| 187 | +Please ensure that your PR description includes: |
39 | 188 |
|
40 |
| -## Commit and PR Guidelines |
| 189 | +- A summary of the changes made. |
| 190 | +- The reason for the changes. |
| 191 | +- Any relevant issues or discussions. |
41 | 192 |
|
42 |
| -- One logical change per commit |
43 |
| -- Always add sign-off: |
44 |
| - ```bash |
45 |
| - git commit -s -m "Add test for Bluetooth functionality" |
46 |
| - ``` |
| 193 | +--- |
47 | 194 |
|
48 |
| -- Mention reviewers if needed and explain validation steps |
49 |
| -- PRs should be raised against `main` unless otherwise noted |
| 195 | +## 🤝 Code of Conduct |
50 | 196 |
|
51 |
| -## License |
| 197 | +We are committed to fostering a welcoming and respectful community. Please adhere to our [Code of Conduct](docs/CODE_OF_CONDUCT.md) in all interactions. |
52 | 198 |
|
53 |
| -All contributions must include: |
54 |
| -```sh |
55 |
| -# Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. |
56 |
| -# SPDX-License-Identifier: BSD-3-Clause-Clear |
| 199 | +--- |
| 200 | + |
| 201 | +Thank you for contributing to **qcom-linux-testkit**! |
| 202 | + |
| 203 | + |
| 204 | +--- |
| 205 | + |
| 206 | +## 🗂️ Test Organization Guidelines |
| 207 | + |
| 208 | +### Directory Placement |
| 209 | + |
| 210 | +- Kernel-level tests → `Runner/suites/Kernel/FunctionalArea/` |
| 211 | +- Multimedia tests → `Runner/suites/Multimedia/` |
| 212 | +- Shared test utilities or binaries → `Runner/common/` |
| 213 | + |
| 214 | +### Script Naming |
| 215 | + |
| 216 | +- Main test launcher must be named `run.sh` |
| 217 | +- Helper scripts should use lowercase with underscores, e.g. `validate_cache.sh` |
| 218 | +- Avoid spaces or uppercase letters in filenames |
| 219 | + |
| 220 | +--- |
| 221 | + |
| 222 | +## ⏱️ Test Execution & Timeout Guidelines |
| 223 | + |
| 224 | +- Tests must be self-contained and deterministic |
| 225 | +- Long-running tests should support intermediate logging or status messages |
| 226 | +- Do not rely on `/tmp` or external mounts |
| 227 | +- Scripts must **fail fast** on invalid setup or missing dependencies |
| 228 | + |
| 229 | +--- |
| 230 | + |
| 231 | +## 📄 Supported Test Artifacts |
| 232 | + |
| 233 | +Optional per-suite files: |
| 234 | +- `enabled_tests.list`: whitelist of subtests to run |
| 235 | +- `*.log`: output logs from each run; should reside in the same directory |
| 236 | +- `*.res`: REQUIRED file that indicates test result in CI/CD |
| 237 | + |
| 238 | +### .res File Format |
| 239 | + |
| 240 | +Valid output examples: |
57 | 241 | ```
|
| 242 | +PASS Foo_Validation |
| 243 | +FAIL Foo_Validation |
| 244 | +SKIP Foo_Validation (missing dependency) |
| 245 | +``` |
| 246 | + |
| 247 | +This format ensures automated tools and LAVA jobs can collect test outcomes. |
| 248 | + |
| 249 | +--- |
| 250 | + |
| 251 | +## 🧩 Shell Compatibility |
| 252 | + |
| 253 | +All scripts must run in POSIX `sh`. **Avoid Bash-only features**, including: |
| 254 | + |
| 255 | +- `local` keyword (use plain assignment) |
| 256 | +- `[[ ... ]]` conditions (use `[ ... ]`) |
| 257 | +- Arrays |
| 258 | +- Bash-style arithmetic without quoting (`$(( ))`) |
| 259 | +- Here-strings or `<<<` |
| 260 | + |
| 261 | +Use `#!/bin/sh` in all test scripts and validate with `ShellCheck`. |
| 262 | + |
| 263 | +--- |
| 264 | + |
| 265 | +## 🧪 CI Integration Notes |
| 266 | + |
| 267 | +Our CI/CD pipeline expects: |
| 268 | +- Each test case to create a `.res` file in the same folder |
| 269 | +- No stdout/stderr pollution unless via `log_*` functions |
| 270 | +- Proper exit codes (0 for pass, 1 for fail) |
| 271 | + |
| 272 | +All logs should remain local to the suite folder, typically named `*.log`. |
| 273 | + |
| 274 | +--- |
58 | 275 |
|
59 |
| -## Questions? |
| 276 | +## 🙋 Questions? |
60 | 277 |
|
61 |
| -Open an issue or start a discussion under the GitHub Issues tab. |
| 278 | +If you're unsure where your test fits or how to structure it, open an issue or tag a maintainer in a draft PR. We're happy to help guide your first contribution. |
0 commit comments