Project

General

Profile

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
Add picture from clipboard (Maximum size: 48.8 MB)