|
| 1 | +# Code Coverage Generation |
| 2 | + |
| 3 | +We have nightly code coverage generation so that we can track test coverage |
| 4 | +for Node.js, make the information public and then use that information |
| 5 | +to improve coverage over time. |
| 6 | + |
| 7 | +At this time we only capture coverage results once a day on linux x86. We |
| 8 | +believe that coverage will not vary greatly across platforms and that the |
| 9 | +process will be too expensive to run on every commit. We will re-evaluate |
| 10 | +these assumptions based on data once the process has been in place for |
| 11 | +a while. |
| 12 | + |
| 13 | +This doc captures the infrastructure in place to support the generation |
| 14 | +of the coverage information published to https://coverage.nodejs.org. |
| 15 | + |
| 16 | +# Steps |
| 17 | + |
| 18 | +Generation/publication of the code coverage results consists of the following: |
| 19 | + |
| 20 | +* Nightly scheduled job - We have a job in jenkins which is scheduled to run at |
| 21 | + 11 EST each night. |
| 22 | + [node-test-commit-linux-coverage](https://ci.nodejs.org/view/All/job/node-test-commit-linux-coverage/). |
| 23 | +* At the end of the scheduled job it rsync's the generated data to the |
| 24 | + benchmarking data machine. We do this so that once the job is complete |
| 25 | + the data is in a place where we know we can pull it from, and that pulling |
| 26 | + that data will not affect any other jobs (for example jobs measuring |
| 27 | + performance on the benchmark machine). |
| 28 | +* At hourly intervals the the data is rsync'd from the benchmarking |
| 29 | + data machine to the website. This is triggered from the nodejs.org website |
| 30 | + machine and data is pulled from the benchmarking data machine. This allows |
| 31 | + us to minimize who can modify the nodejs.org website as no additional |
| 32 | + access is required. |
| 33 | + |
| 34 | +# Coverage Job |
| 35 | + |
| 36 | +The coverage job follows the same pattern as our other build jobs in order |
| 37 | +to check out the version of node to be build/tested. It requires the following |
| 38 | +additions: |
| 39 | + |
| 40 | +1. Build/test with the coverage targets. This is currently: |
| 41 | + |
| 42 | + ``` |
| 43 | + ./configure --coverage |
| 44 | + make coverage-clean |
| 45 | + NODE_TEST_DIR=${HOME}/node-tmp PYTHON=python COVTESTS=test-ci make coverage -j $(getconf _NPROCESSORS_ONLN) |
| 46 | + ``` |
| 47 | + |
| 48 | +2. Generate html summary page and push results to the benchmarking data machine: |
| 49 | + |
| 50 | + ``` |
| 51 | + #!/bin/bash |
| 52 | +
|
| 53 | + # copy the coverage results to the directory where we keep them |
| 54 | + # generate the summaries and transfer to the benchmarking data |
| 55 | + # machine from which the website will pull them |
| 56 | +
|
| 57 | + export PATH="$(pwd):$PATH" |
| 58 | +
|
| 59 | + # copy over results |
| 60 | + COMMIT_ID=$(git rev-parse --short=16 HEAD) |
| 61 | + mkdir -p "$HOME/coverage-out" |
| 62 | + OUTDIR="$HOME/coverage-out/out" |
| 63 | + mkdir -p "$OUTDIR" |
| 64 | + rm -rf "$OUTDIR/coverage-$COMMIT_ID" || true |
| 65 | + cp -r coverage "$OUTDIR/coverage-$COMMIT_ID" |
| 66 | +
|
| 67 | + # add entry into the index and generate the html version |
| 68 | + JSCOVERAGE=$(grep -B1 Lines coverage/index.html | \ |
| 69 | + head -n1 | grep -o '[0-9\.]*') |
| 70 | + CXXCOVERAGE=$(grep -A3 Lines coverage/cxxcoverage.html | \ |
| 71 | + grep style | grep -o '[0-9]\{1,3\}\.[0-9]\{1,2\}') |
| 72 | + NOW=$(date -u +"%Y-%m-%dT%H:%M:%SZ") |
| 73 | +
|
| 74 | + echo "$JSCOVERAGE,$CXXCOVERAGE,$NOW,$COMMIT_ID" >> "$OUTDIR/index.csv" |
| 75 | +
|
| 76 | + cd $OUTDIR/.. |
| 77 | + $WORKSPACE/testing/coverage/generate-index-html.py |
| 78 | +
|
| 79 | + # transfer results to machine where coverage data is staged. |
| 80 | + rsync -r out coveragedata:coverage-out |
| 81 | + ``` |
| 82 | + |
| 83 | +The current setup depends on past runs being in /home/iojs/coverage-out/out |
| 84 | +on the machine that it is run on so that the generated index |
| 85 | +includes the current and past data. For this and other reasons described |
| 86 | +in the other sections, the job is pegged to run on: |
| 87 | +[iojs-softlayer-benchmark](https://ci.nodejs.org/computer/iojs-softlayer-benchmark/) |
| 88 | + |
| 89 | + |
| 90 | +# Tranfer to benchmarking data machine |
| 91 | +The rsync from the machine on which the job runs to the benchmarking |
| 92 | +data machine requires an ssh key. Currently we have pegged the job to the |
| 93 | +benchmarking machine |
| 94 | +[iojs-softlayer-benchmark](https://ci.nodejs.org/computer/iojs-softlayer-benchmark/), |
| 95 | +have installed the key there, and have added an entry in |
| 96 | +the ```.ssh/config``` file for the iojs user so that connections to the |
| 97 | +'coveragedata' go to the benchmarking machine and use the correct key |
| 98 | +(uses the softlayer internal network as opposed to public ip) |
| 99 | + |
| 100 | +``` |
| 101 | +Host coveragedata |
| 102 | + HostName 10.52.6.151 |
| 103 | + User benchmark |
| 104 | + IdentityFile ~/coverage-out/key/id_rsa |
| 105 | +``` |
| 106 | + |
| 107 | +The results are pushed to /home/benchmark/coverage-out/out. |
| 108 | + |
| 109 | +# Transfer to the website |
| 110 | +As mentioned earlier, the website will pull updates hourly from |
| 111 | +/home/benchmark/coverage-out/out and put |
| 112 | +them in the right place to be served at coverage.nodejs.org. The key |
| 113 | +required to do this is already in place in order to support the similar process |
| 114 | +for benchmarking.nodejs.org |
0 commit comments