Linting: Vint
Aim
This MR accomplishes part of #11, namely to lint the Vim files in the package with vint
. This is partially an MR of the vint
pipeline step directly, but should also serve as a vetting of the standards set by the vint
job, which will surely be mimicked by other linting jobs that come along next. Vint is a good one to start with because it:
- Is in the official repos
- Has very little feedback for existing code, and so is easy to fix. I'd mostly be comfortable addressing the Shellcheck feedback but there's quite a lot of it, and there's minimal CPPCheck feedback but that's not as much my forte.
Workflow
The workflow
section of the pipeline saves us from having to specify the same running rules to all the jobs, Gitlab docs here: https://docs.gitlab.com/ee/ci/yaml/workflow.html
Structure
I added the job without separating them out into stages, which in practice puts the vint
and test
jobs together in an implicit stage called test
, and the jobs can run in parallel. I considered making a separate stage for lint
but since there isn't actually a run dependency between the stages, that seemed unnecessary.
Another option is in Merge Requests, running the linter only when files governed by it are touched. This has the advantage that if a linter changes styling, someone contributed unrelated code won't be hit by it; the pipeline would just fail after merge to master. I haven't implemented that here but can if that's desired.
This is what the pipeline jobs look like structurally now then:
Vint
I decided to use Arch as the base image because Vint is easily found in the official repos and it mimics the test
job. This could have the side effect that if Vint (or another linter) changes its styling, pipelines here will start failing as soon as that update hits Arch, and updates will need to be made to appease the linter. This could be avoided by using a different base image, pinning to a specific Vint version, and updating intentionally over time, but honestly that's more likely to fall out of date so I don't prefer it.
I ended up using bash
's globstar
shopt
as that felt like the simplest way to make this happen in just one invocation of Vint, and therefore just have one exit code to decide the failure state of the pipeline. find
, xargs
, and other options had these or similar pitfalls.
You can see an example of a failed pipeline here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/pipelines/72749 with its failed vint job here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/jobs/165013
And a successful pipeline here, after addressing the linter's feedback: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/pipelines/72751 with its successful vint job here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/jobs/165019
Explanation of linter feedback changes here: https://vimhelp.org/autocmd.txt.html#autocmd-groups
Let me know if you have any questions, or feel anything should be different.