Project

General

Profile

Linting » History » Version 6

osmith, 01/17/2022 04:09 PM
document program specific configuration

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
$ git clone https://git.osmocom.org/osmo-ci
11
$ cd libosmocore
12
$ ../osmo-ci/lint/lint_diff.sh
13
</pre>
14
15
h2. Pre-commit hook
16
17 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@.
18
19 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.
20 1 osmith
<pre>
21
$ ln -sv $PWD/osmo-ci/lint/lint_diff.sh libosmocore/.git/hooks/pre-commit
22
</pre>
23
24
h2. Osmocom specific configuration
25
26
Find the Osmocom specific configuration in @osmo-ci/lint/checkpatch/checkpatch_osmo.sh@.
27
28 6 osmith
h3. Project specific configuration
29
30
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.
31
32
Example:
33
<pre>
34
--ignore OPEN_BRACE
35
--ignore POINTER_LOCATION
36
--ignore SPACING
37
</pre>
38
39 1 osmith
h2. Testing
40
41
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:
42
43
<pre>
44
$ cd libosmocore
45
$ ../osmo-ci/lint/lint_all.sh CODE_INDENT
46
</pre>
47 4 osmith
48
h2. What if errors from the linter don't make sense?
49
50 5 osmith
If it's trivial to fix, consider submitting a patch against osmo-ci.git to fix it yourself. Otherwise create an issue and assign it to osmith.
51 4 osmith
52
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:
53
54
<pre>
55
Build Failed 
56
57
https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw/.../ : SUCCESS
58
59
https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw-lint/.../ : FAILURE
60
</pre>
61
62
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.
63 1 osmith
64
h2. See also
65
66
* #5087
67 6 osmith
* #5399
Add picture from clipboard (Maximum size: 48.8 MB)