Publish a Docker image for CI actions

[boramalper]

Hi,

Thanks for building systemdlint, looks great! It'd be very handy to have a Docker image for it too for using in CI.

Thanks,
Bora

[priv-kweihmann]

The idea is not bad.
I would assume such a docker should then launch the tool automatically with a recommended set of options (through the entrypoint definition), right?
What options shall that be?
The linter itself can operate on a root file like folder structures or (with a reduced set of lints) on just files.
First option requiring the folder then to be mounted into the container.

What I could see is a docker image being part of the #75 story - even though it would be a bit much to create a few hundreds of MB large container image just for this tool, while python's venv (similar to what pre-commit does) could give you the same results with less disk consumption.
So in conclusion pre-commit support would be my priority (which can be used in CI easily) likely making this story here obsolete.

[boramalper]

I would assume such a docker should then launch the tool automatically with a recommended set of options (through the entrypoint definition), right?

I'd say that docker should launch systemdlint without any command-line arguments (i.e. ENTRYPOINT ["systemdlint"]), which I believe is the convention for such images.

However, for most CI tools it doesn't matter:

The linter itself can operate on a root file like folder structures or (with a reduced set of lints) on just files.
First option requiring the folder then to be mounted into the container.

I use Woodpecker CI on Codeberg (a free and open GitHub alternative hosted by a non-profit), and Woodpecker CI works similarly to GitLab's:

image: Tell the runner which Docker container to use to run the job in. The runner:

• Downloads the container image and starts it.
• Clones your GitLab project into the running container.
• Runs the script commands, one at a time.

So to answer your question about how the linter itself can operate: it doesn't matter as long as systemdlint is in PATH. The user will write "script commands" (i.e. shell commands) that invoke systemdlint however they like. For example:

build-job:
  image: ghcr.io/priv-kweihmann/systemdlint
  script:
    - systemdlint my-service.service my-service.timer

So in conclusion pre-commit support would be my priority (which can be used in CI easily) likely making this story here obsolete.

I agree that they're complementary but I cannot follow how pre-commit support would make CI support obsolete. CI is used to test and lint others' (i.e. external) contributions too, and external contributors may not have pre-commit configured (as it requires trusting custom scripts running on your machine).

[priv-kweihmann]

I agree that they're complementary but I cannot follow how pre-commit support would make CI support obsolete. CI is used to test and lint others' (i.e. external) contributions too, and external contributors may not have pre-commit configured (as it requires trusting custom scripts running on your machine).

Basically you can then use any of the trillion available pre-commit container and control the linter invoked on a repo basis, which makes is a) much more flexible and b) doesn't require a custom container just for this linter here.

Background is that I find it a bit much work to create a Docker image (versioned ofc) just for this tool (feels completely overkill), thus I'm more in favor of solutions that can be reused for other purposes too.