Linting » History » Version 10
laforge, 11/23/2022 12:27 PM
1 | 1 | osmith | h1. Linting |
---|---|---|---|
2 | |||
3 | Patches submitted to [[Gerrit]] are automatically linted to ensure patches follow our [[coding standards]] and to catch common spelling errors. Jenkins runs @checkpatch.pl@ from the Linux kernel (with an Osmocom specific configuration) against the diff of the current patch. |
||
4 | |||
5 | 2 | osmith | h2. Run locally |
6 | 1 | osmith | |
7 | 2 | osmith | Go to the directory above your Osmocom sources, then run the following: |
8 | |||
9 | <pre> |
||
10 | 9 | laforge | $ git clone https://gitea.osmocom.org/osmocom/osmo-ci |
11 | 2 | osmith | $ ../osmo-ci/lint/lint_diff.sh |
12 | </pre> |
||
13 | |||
14 | h2. Pre-commit hook |
||
15 | |||
16 | 1 | osmith | The linting script is very fast, it makes sense to configure it locally as pre-commit hook. Then it will run whenever attempting to @git commit@. |
17 | |||
18 | 3 | osmith | After cloning osmo-ci.git (see above), go to the directory above your Osmocom sources again and run the following. Replace libosmocore with any checked out Osmocom project. |
19 | 1 | osmith | <pre> |
20 | $ ln -sv $PWD/osmo-ci/lint/lint_diff.sh libosmocore/.git/hooks/pre-commit |
||
21 | </pre> |
||
22 | |||
23 | h2. Osmocom specific configuration |
||
24 | |||
25 | Find the Osmocom specific configuration in @osmo-ci/lint/checkpatch/checkpatch_osmo.sh@. |
||
26 | |||
27 | 6 | osmith | h3. Project specific configuration |
28 | |||
29 | It is possible to have project specific ignores for linter checks, by creating a <code>.checkpatch.conf</code> file inside the top directory of the git repository. In that file, each line is a command-line argument to checkpatch.pl. |
||
30 | |||
31 | 8 | osmith | Examples: |
32 | 1 | osmith | <pre> |
33 | 8 | osmith | --exclude ^src/sbcap/(skel|gen)/.*\.(c|h)$ |
34 | --exclude ^src/sbcap/.*\.asn$ |
||
35 | 6 | osmith | --ignore OPEN_BRACE |
36 | --ignore POINTER_LOCATION |
||
37 | --ignore SPACING |
||
38 | </pre> |
||
39 | |||
40 | 1 | osmith | h2. Testing |
41 | |||
42 | Run @osmo-ci/lint/lint_all.sh@ in a git repository to run the script against all files in that repository and to report the total amount of errors. It is also possible to run only a specific check of @checkpatch.pl@ by passing it as argument. For example: |
||
43 | |||
44 | <pre> |
||
45 | $ cd libosmocore |
||
46 | $ ../osmo-ci/lint/lint_all.sh CODE_INDENT |
||
47 | </pre> |
||
48 | 4 | osmith | |
49 | 7 | osmith | h2. Ignoring lint failures |
50 | 4 | osmith | |
51 | 7 | osmith | If a reported failure from the linter does not make sense, and it is trivial, consider submitting a patch against osmo-ci.git to fix it yourself. Otherwise create an issue and assign it to osmith. |
52 | 4 | osmith | |
53 | The linter job runs separately from the build verification job. If building a patch succeeds, but the linter fails on it, jenkins will leave a comment like the following in the gerrit review: |
||
54 | |||
55 | <pre> |
||
56 | Build Failed |
||
57 | |||
58 | https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw/.../ : SUCCESS |
||
59 | |||
60 | https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw-lint/.../ : FAILURE |
||
61 | </pre> |
||
62 | |||
63 | So from looking at this comment, it's clear that building did succeed any only linting failed. If that is the case and the linter's output isn't helpful, remove the -1 build verification vote from jenkins and add your own +1 build verification. Then it can be merged regardless of the linting errors. |
||
64 | 1 | osmith | |
65 | h2. See also |
||
66 | |||
67 | * #5087 |
||
68 | 6 | osmith | * #5399 |