|
| 1 | + |
| 2 | +# Adding New Project |
| 3 | + |
| 4 | +If you want to add a new project into the `openctest` framework. You need to do the following steps. |
| 5 | + |
| 6 | +## 1. Instrument Target Project |
| 7 | + |
| 8 | + |
| 9 | +**Because intercepting and logging the configuration APIs are for two independent purposes -- and their outcome are independent of each other, it is **highly recommended** to create a separate Git branch for each case.** |
| 10 | + |
| 11 | +### 1.1 Intercept Configuration API (Paper Section 4.1) |
| 12 | + |
| 13 | +Intercept the configuration API to overwrite configuration values in the final step of configuration loading. |
| 14 | + |
| 15 | +Specifically, create empty configuration file(s) in the project directory, and make sure the configuration API reads it in the final step of configuration loading. So when the test reads configuration values from the APIs, the values come from the configurations maintained by the ctest infrastructure. |
| 16 | + |
| 17 | +Intercept example in Hadoop: |
| 18 | +- [override configuration loading](https://github.com/xlab-uiuc/hadoop/commit/72a9e108e4c2bed13b43d8b4fbd3aa32e690447c#diff-16e961a312f55e9abdc96aa97dec8b284b79ab6d10ca6f2332c66a3f8aa96529) |
| 19 | +- [the configuration file created for overriding](https://github.com/xlab-uiuc/hadoop/commit/72a9e108e4c2bed13b43d8b4fbd3aa32e690447c#diff-ad606c23074a9dff0050b0e57746fa6865c2151bcf940fda692d540dfde9b74f) |
| 20 | + |
| 21 | +*This instrumentation is for generating and running ctests, and is needed by the `generate_ctest` and `run_ctest`.* |
| 22 | + |
| 23 | +### 1.2 Logging Configuration API (Paper Section 4.2) |
| 24 | + |
| 25 | +Identify and instrument the configuration GET and SET APIs which read and write configuration values. |
| 26 | + |
| 27 | +The instrumentation should log the GET and SET API usage on each exercised configuration parameter in a specific format. So the ctest infrastructure can identify the parameters exercised in each test by running the tests and parsing the test logs. |
| 28 | + |
| 29 | +GET instrumentation example: [hadoop-common](https://github.com/xlab-uiuc/hadoop/commit/cd8c6d5a2a11298731355c399a1e563234713e97#diff-16e961a312f55e9abdc96aa97dec8b284b79ab6d10ca6f2332c66a3f8aa96529R1104) |
| 30 | + |
| 31 | +SET instrumentation example: [hadoop-common](https://github.com/xlab-uiuc/hadoop/commit/cd8c6d5a2a11298731355c399a1e563234713e97#diff-16e961a312f55e9abdc96aa97dec8b284b79ab6d10ca6f2332c66a3f8aa96529R1275) |
| 32 | + |
| 33 | +*This instrumentation is for identifying parameters exercised by tests, and is needed by `identify_param`.* |
| 34 | + |
| 35 | + |
| 36 | +## 2. Add Supporting Code in `openctest` |
| 37 | + |
| 38 | +### *2.0 Modify Maven pom.xml |
| 39 | + |
| 40 | +The `maven-surefire-plugin` controls how the testing result is generated. Errors may be caused by discrepancies in the plugin version or test report format. It is important to ensure all supporting projects at least use the same plugin version. To do so, please modify the `pom.xml` in new project. |
| 41 | + |
| 42 | +Sometimes, the locations that need to be changed maybe in multiple `pom` files. For example, for supporting project `hadoop-common`: |
| 43 | +- `maven-surefire-plugin` version in [hadoop-common-project/hadoop-common/pom.xml](https://github.com/xlab-uiuc/hadoop/commit/cd8c6d5a2a11298731355c399a1e563234713e97#diff-32126fb088c541b420c68ba15eacf1f1a78d842f71595ba9ed1cbf25c530fa07 "hadoop-common-project/hadoop-common/pom.xml") |
| 44 | +- `maven-surefire-plugin` report format in [pom.xml](https://github.com/xlab-uiuc/hadoop/commit/72a9e108e4c2bed13b43d8b4fbd3aa32e690447c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8 "pom.xml") |
| 45 | + |
| 46 | +### 2.1 Collect Configuration Parameters and Tests |
| 47 | + |
| 48 | +*First*, collect the name, default value (empty if no default value) and description of each configuration parameters in the project. Store the information in a `tsv` file in `default_configs`. For example: [hadoop-common-default.tsv](https://github.com/xlab-uiuc/openctest/blob/master/core/default_configs/hadoop-common-default.tsv). |
| 49 | + |
| 50 | + *Second*, collect the list of configuration parameter names and put them in `openctest/core/identify_param/results/<project>/conf_params.list`. |
| 51 | + |
| 52 | +*Third*, collect the list of exsiting tests in the project in the format of `testClass#testCase`. Put them in `openctest/core/identify_param/results/<project>/test_method_list.json` |
| 53 | + |
| 54 | + |
| 55 | +### 2.2 Collect Deprecated Configuration Parameters |
| 56 | + |
| 57 | +Collect a mapping from the deprecated parameter name to the new parameter name. Store the information in a `tsv` file in `deprecated_configs`. The format should be the deprecated parameter name followed by the new parameter name. For example: [hadoop.list](https://github.com/xlab-uiuc/openctest/blob/master/core/deprecated_configs/hadoop.list "hadoop.list") |
| 58 | + |
| 59 | + |
| 60 | +### 2.3 Automate Project Installation |
| 61 | + |
| 62 | +*First*, in `add_project.sh`, add a bash function for cloning, installing, and building the instrumented new project. And it should also automatically switch to the branch with instrumented code for *1.1 Intercept Configuration API*. |
| 63 | + |
| 64 | +Example for the `hadoop-common` module in Hadoop: |
| 65 | + |
| 66 | +```Bash |
| 67 | +function setup_hadoop() { |
| 68 | + [ ! -d "app/ctest-hadoop" ] && git clone git@github.com:xlab-uiuc/hadoop.git app/ctest-hadoop |
| 69 | + cd app/ctest-hadoop |
| 70 | + git fetch && git checkout ctest-logging |
| 71 | + home_dir=$PWD |
| 72 | + cd $home_dir/hadoop-common-project/hadoop-common |
| 73 | + mvn clean install -DskipTests |
| 74 | + cd $home_dir/hadoop-hdfs-project/hadoop-hdfs-client |
| 75 | + mvn clean install -DskipTests |
| 76 | + cd $home_dir/hadoop-hdfs-project/hadoop-hdfs |
| 77 | + mvn package -DskipTests |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | +*Second*, in `identify_param/add_project.sh`, add a bash function for cloning, installing, and building the instrumented new project. And it should also automatically switch to the branch with instrumented code for *1.2 Logging Configuration API*. |
| 82 | + |
| 83 | +Using `hadoop-common` as an example, the difference is just: |
| 84 | + |
| 85 | +```Bash |
| 86 | + ... |
| 87 | + git fetch && git checkout ctest-injection |
| 88 | + ... |
| 89 | +``` |
| 90 | + |
| 91 | +### 2.3 Add Project Specific Constants |
| 92 | + |
| 93 | +*First*, add project-specific constants to `ctest_const.py` for generating and running ctests. This constant file is used by `generate_ctest` and `run_ctest`. The constants include but not limited to |
| 94 | +- project name, like `hadoop-common`, `hadoop-hdfs`, etc |
| 95 | +- target project directory |
| 96 | +- path(s) to generated surefire report |
| 97 | +- path to default configuration parameters file (2.1) |
| 98 | +- path to deprecated configuration parameters file (2.2) |
| 99 | +- path(s) to configuration files that are used to intercept the configuration API (1.1), like [this](https://github.com/xlab-uiuc/openctest/blob/554fff9c017b99f482da8240f16a000cfd4eb82d/core/ctest_const.py#L82) |
| 100 | + |
| 101 | +*Second*, add project-specific constants to `identify_param/constant.py` for identifying parameters exercised by tests. This constant file is used by `identify_param`. |
0 commit comments