|
| 1 | +As of now, the GitHub CI is designed to run in three instances: |
| 2 | +1. An individual component basis, meaning if a component's codebase is updated, we will only run CI tests for that component. As an example, if we update `cupti_profiler.c` in `src/components/cuda`, we will only run CI tests for the cuda component. Note that this includes updates to subdirectories located in a component's directory (e.g. `src/components/cuda/tests`). See the **NOTE** in [Individual Component Basis](#individual-component-basis) for more info on the setup for the default components (`perf_event`, `perf_event_uncore`, and `sysdetect`). |
| 3 | +2. A change to the Counter Analysis Toolkit i.e. in the `src/counter_analysis_toolkit` directory and any subdirectories. |
| 4 | +3. A change in the PAPI framework i.e. in the `src/` directory or `src/` subdirectories (excluding individual components and the Counter Analysis Toolkit). If this occurs then we will run a full test suite. |
| 5 | + |
| 6 | + |
| 7 | +# Individual Component Basis |
| 8 | +All individual component basis tests have a `.yml` that is structured with `componentName_component_workflow.yml`. As |
| 9 | +an example for the `cuda` component we would have a `.yml` of `cuda_component_workflow.yml`. Therefore, |
| 10 | +if a new component is added to PAPI, you will need to create a `.yml` based on the aforementioned structure. |
| 11 | + |
| 12 | +Upon creating the `.yml` file, you will need to add a workflow. Below is a skeleton that can |
| 13 | +be used as a starting point. As a reminder, make sure to change the necessary fields out for your component. |
| 14 | + |
| 15 | +```yml |
| 16 | +name: cuda # replace cuda with your component name |
| 17 | + |
| 18 | +on: |
| 19 | + pull_request: |
| 20 | + paths: |
| 21 | + - 'src/components/cuda/**' # replace the cuda path with your component path |
| 22 | + |
| 23 | +jobs: |
| 24 | + component_tests: |
| 25 | + strategy: |
| 26 | + matrix: |
| 27 | + component: [cuda] # replace cuda with your component name |
| 28 | + debug: [yes, no] |
| 29 | + shlib: [with, without] |
| 30 | + fail-fast: false |
| 31 | + runs-on: [self-hosted, nvidia_gpu] |
| 32 | + timeout-minutes: 60 |
| 33 | + steps: |
| 34 | + - uses: actions/checkout@v4 |
| 35 | + - name: cuda component tests # replace cuda with your component name |
| 36 | + run: .github/workflows/ci_individual_component.sh ${{matrix.component}} ${{matrix.debug}} ${{matrix.shlib}} |
| 37 | +```` |
| 38 | + |
| 39 | +For each component `.yml`, there will be a single job with the options of: |
| 40 | + - `component`, this is the component we want to configure PAPI with (e.g. cuda) |
| 41 | + - `debug`, with the options of either `yes` (builds a debug version) or `no` (does not build a debug version) |
| 42 | + - `shlib`, with `--with-shlib-tools` or without `--with-shlib-tools` |
| 43 | + |
| 44 | +These options will be used in the script `ci_individual_component.sh` to test configuring and building PAPI. |
| 45 | + |
| 46 | +Besides configuring and building PAPI, `ci_individual_component.sh` will: |
| 47 | + - Check to make sure components are active that we expect |
| 48 | + - Run a test suite using either `run_tests.sh` (without `--with-shlib-tools`) or `run_tests_shlib.sh` (with `--with-shlib-tools`) |
| 49 | + |
| 50 | +**NOTE**: The components `perf_event`, `perf_event_uncore`, and `sysdetect` do not follow the above outlined file structure. |
| 51 | +For these three components the files used are `default_components_workflow.yml` and `ci_default_components.sh`. Even though |
| 52 | +the file structure is different the workflow will still only run if a change is made to one of their directories or subdirectories. |
| 53 | +The reason for this is that these three components are compiled in by default and trying to pass one of them to `--with-components=` |
| 54 | +will result in an error during the build process. Therefore, any PAPI CI updates for one of these three components would need to be |
| 55 | +addressed in either of the two aforementioned files. |
| 56 | + |
| 57 | +# Counter Analysis Toolkit |
| 58 | +The Counter Analysis Toolkit (CAT) CI uses the `cat_workflow.yml` and `ci_cat.sh` files. Any updates to the CI for CAT need to be done in these two files. |
| 59 | + |
| 60 | +The `cat_workflow.yml` will have a single job with the options of: |
| 61 | + - `debug`, with the options of either `yes` (builds a debug version) or `no` (does not build a debug version) |
| 62 | + - `shlib`, with `--with-shlib-tools` or without `--with-shlib-tools` |
| 63 | + |
| 64 | +These options will be used in the script `ci_cat.sh` to test configuring and building PAPI. |
| 65 | + |
| 66 | +Besides configuring and building PAPI `ci_cat.sh` will: |
| 67 | +- Test building CAT |
| 68 | +- Check to see if CAT successfully detects the architecture we are on |
| 69 | +- Run CAT with a real event and a dummy event |
| 70 | + - For the real event, we expect the file to exist and values to be present |
| 71 | + - For the dummy event, we expect the file to exist, but values to not be present |
| 72 | + |
| 73 | +# PAPI Framework |
| 74 | +The PAPI framework CI uses the `papi_framework_workflow.yml` along with the scripts `clang_analysis.sh`, `ci_papi_framework.sh`, and `spack.sh`. Any updates to the CI for the PAPI framework need to be done in these files. |
| 75 | + |
| 76 | +`papi_framework_workflow.yml` will have a total of five jobs: |
| 77 | +1. papi_components_comprehensive |
| 78 | + - With the options of: |
| 79 | + - `components`, this is the components we want to configure PAPI with, i.e. `cuda nvml rocm rocm_smi powercap powercap_ppc rapl sensors_ppc infiniband net appio io lustre stealtime` |
| 80 | + - `debug`, with the options of either `yes` (builds a debug version) or `no` (does not build a debug version) |
| 81 | + - `shlib`, with `--with-shlib-tools` or without `--with-shlib-tools` |
| 82 | + |
| 83 | +2. papi_components_amd |
| 84 | + - With the options of: |
| 85 | + - `components`, this is the components we want to configure PAPI with, i.e. `rocm rocm_smi` |
| 86 | + - `debug`, with the options of either `yes` (builds a debug version) or `no` (does not build a debug version) |
| 87 | + - `shlib`, with `--with-shlib-tools` or without `--with-shlib-tools` |
| 88 | + |
| 89 | +3. papi_component_infiniband |
| 90 | + - With the options of: |
| 91 | + - `component`, this is the component we want to configure PAPI with, i.e. `infiniband` |
| 92 | + - `debug`, with the options of either `yes` (builds a debug version) or `no` (does not build a debug version) |
| 93 | + - `shlib`, with `--with-shlib-tools` or without `--with-shlib-tools` |
| 94 | + |
| 95 | +4. papi_spack |
| 96 | + - The script `spack.sh` will be ran, which configures and builds PAPI from SPACK |
| 97 | + |
| 98 | +5. papi_clang_analysis |
| 99 | + - The script `clang_analysis.sh` will be ran, which configures and builds PAPI with clang |
| 100 | + |
| 101 | +For jobs 1, 2, and 3, the options listed will be used in the script `ci_papi_framework.sh` to test configuring and building PAPI. |
| 102 | + |
| 103 | +Besides configuring and building PAPI, `ci_papi_framework.sh` will: |
| 104 | + - Check to make sure components are active that we expect |
| 105 | + - Run a test suite using either `run_tests.sh` (without `--with-shlib-tools`) or `run_tests_shlib.sh` (with `--with-shlib-tools`) |
0 commit comments