Cellular Network Infrastructure

h1. Linting

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.

h2. Run locally

Go to the directory above your Osmocom sources, then run the following:

<pre>

$ git clone https://gitea.osmocom.org/osmocom/osmo-ci

$ cd libosmocore

$ ../osmo-ci/lint/lint_diff.sh

</pre>

h2. Pre-commit hook

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@.

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.

<pre>

$ ln -sv $PWD/osmo-ci/lint/lint_diff.sh libosmocore/.git/hooks/pre-commit

</pre>

h2. Osmocom specific configuration

Find the Osmocom specific configuration in @osmo-ci/lint/checkpatch/checkpatch_osmo.sh@.

h3. Project specific configuration

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.

Examples:

<pre>

--exclude ^src/sbcap/(skel|gen)/.*\.(c|h)$

--exclude ^src/sbcap/.*\.asn$

--ignore OPEN_BRACE

--ignore POINTER_LOCATION

--ignore SPACING

</pre>

h2. Notes on linter behavior

h3. Interpreting multi-line comments as code

If a multi-line comment gets linted as code, then it is probably missing the star at the beginning of each comment line.

<pre>

/* Multi-line

 * comment

 * example */

</pre>

h2. Testing

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:

<pre>

$ cd libosmocore

$ ../osmo-ci/lint/lint_all.sh CODE_INDENT

</pre>

h2. Ignoring lint failures

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.

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:

<pre>

Build Failed 

https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw/.../ : SUCCESS

https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-mgw-lint/.../ : FAILURE

</pre>

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.

h2. See also

* #5087

* #5399