Add unified `make` target to run all CI linters locally

[IrvingMg]

Currently, make lint only runs golangci-lint, while CI runs four separate lint checks. The other three have no local equivalent, making it easy to miss issues that only surface after pushing.

CI Lint Checks vs. Local Availability

• golangci-lint: available locally
• cspell: no local target
• commitlint: no local target
• license-eye: no local target

Proposed Changes

1. Add a unified Make target

Introduce a new target (e.g., make verify) that runs all CI linters, allowing contributors to catch issues locally before pushing, while still preserving individual targets for each check.

2. Update CI to use Make targets

Modify CI workflows to call the same Make targets instead of invoking tools directly. This keeps local and CI behavior consistent and ensures linting changes are made in one place.

[cmainas]

Hello @IrvingMg ,

this is true and definitely inconvenient. However, I am not sure if it will be a good to require the contributors to have so many tools installed. Maybe, this can be resolved by providing a container with everything required for the tools.

Another approach would be to remove the restriction of requiring an approval for a workflow to execute for non-first time contributors.

[IrvingMg]

this is true and definitely inconvenient. However, I am not sure if it will be a good to require the contributors to have so many tools installed. Maybe, this can be resolved by providing a container with everything required for the tools.

What I had in mind was something like a Makefile-deps.mk. If we consider only linters, we can discuss whether we really need a new Makefile. However, I think we could follow the approach of creating a bin directory inside the project and having the make command download the dependencies automatically.

In this example: https://github.com/kubernetes-sigs/lws/blob/39a2e4c4cbdf0d7725877ae52f2fc5484e3458e2/Makefile#L193-L195 there is a make lint target that depends on golangci-lint, but installing it doesn’t require any extra action from developers.

It seems, though, we can’t follow this approach directly. In the example, all dependencies are binaries that can be easily installed with Go, whereas in our case we have Node dependencies. To implement a similar approach, we would need to check whether they provide precompiled binaries for download or look for alternatives that do. That might not be what we want.

Therefore, I think using a container could be a good approach. This new make target could build and run a container with the local code against all the linters. It’s reasonable to expect developers to have Docker installed, so this shouldn’t require extra steps.

Another approach would be to remove the restriction of requiring an approval for a workflow to execute for non-first time contributors.

I wouldn’t remove the workflow restriction yet. There are benefits to running checks locally first, for example, catching issues as early as possible and keeping the CI workflow reproducible and aligned with the local setup.

[cmainas]

I will add this issue to the roadmap with the following tasks:

• Create a container image with all linters and necessary data
• Add a Makefile target to use the container image for linting (as done with the go linter)

[oindrilakha12-ui]

Hi @IrvingMg, @cmainas,
I’d like to work on this task and create a PR to add a unified make verify target to run all CI linters locally.
I’ll follow a container-based approach so contributors can run all linters without installing each tool manually.

[cmainas]

Hello @oindrilakha12-ui feel free to work on this. However, please share your container image (and Containerfile) here before opening a PR.

[oindrilakha12-ui]

Hi @cmainas, @IrvingMg,

Here’s my proposed container-based approach for issue #491.

Plan:

Add Containerfile.lint at repo root

Base image: golang:1.25-bookworm (matches go.mod / CI)

Install Node.js 22 for JS-based linters

Tools installed:

golangci-lint (latest stable compatible with Go 1.25 — CI currently references v2.7 which appears invalid)

license-eye via go install github.com/apache/skywalking-eyes/cmd/license-eye@latest

npm linters:

cspell@8.19.4

commitlint@18

@commitlint/config-conventional@18

commitlint-plugin-spellcheck

Container setup:

Working directory: /src (project mounted at runtime)

Optional build args for version overrides

Usage (example):
docker build -f Containerfile.lint -t urunc-linter .

docker run --rm -v $(pwd):/src -w /src urunc-linter golangci-lint run
docker run --rm -v $(pwd):/src -w /src urunc-linter cspell --config .github/linters/.cspell.json "**"
docker run --rm -v $(pwd):/src -w /src urunc-linter license-eye -c .github/linters/licenserc.yml header check

If this looks good, I’ll proceed with implementing the Containerfile and then wire it into Makefile and CI.

[cmainas]

Hello @oindrilakha12-ui ,

the plan sounds fine, however the Go based linters already provide their own container images. We can simply reuse them. Therefore, we can restrict the container to the npm linters to reduce the maintenance cost.

Please share your Containerfile and try it out locally for testing.

[oindrilakha12-ui]

Thanks for the feedback!

I’ve restricted the custom container to npm-based linters only and reused official images for Go-based linters as suggested.

Here is the proposed Containerfile.lint:

# syntax=docker/dockerfile:1
# Check https://hub.docker.com/_/node for available versions
ARG NODE_VERSION=22
ARG OS_VERSION=bookworm

FROM node:${NODE_VERSION}-${OS_VERSION}

# Install linters globally
# Versions pinned based on .github/linters/package.json
RUN npm install -g \
    cspell@^8.19.4 \
    commitlint@^18.0.0 \
    @commitlint/config-conventional@^18.0.0 \
    @somehow-digital/commitlint-plugin-spellcheck@^1.1.0

# Set the working directory to /src
WORKDIR /src

# Allow the container to run as an arbitrary user (useful for CI/rootless)
# but default to node user if desired, though often linters run as current user mapped in.
# We'll just set workdir.

CMD ["/bin/bash"]

[IrvingMg]

Thanks for sharing the proposal, @oindrilakha12-ui. I think this is a good starting point, but it could use a bit more refinement. Here are my thoughts:

1. I was thinking that having a single container with all linters might be simpler for developers to run, since one command would execute everything. It would also simplify the Makefile target by avoiding the need to coordinate multiple containers.

   For that, we would also need to include binaries like golangci-lint and license-eye, so we’d need to download them during the build process. We could use a multi-stage build where the linter images serve as build stages, and then copy only the binaries into the final Node-based image.

   @cmainas , what do you think about this approach?

2. If we move to a single container, instead of setting bash as the default command, we could create a bash script that executes all linters by default but also allows passing a specific linter name as an argument. This script could then be used as the ENTRYPOINT.

3. I don’t think we need to use volumes to run the linters. Using the COPY command should be enough to include all local changes.

[oindrilakha12-ui]

Hi @IrvingMg, thanks for the detailed feedback!

I agree that a single container running all linters would simplify both the developer experience and the Makefile target.

Using a multi-stage build to pull the binaries from the official golangci-lint and license-eye images and copying them into a final Node-based image sounds like a clean approach — it keeps the final image minimal while avoiding manual installs.

I also see the benefit of using COPY instead of volume mounts to make the container self-contained.

I’ll prototype a single-container Containerfile.lint using multi-stage builds and a small entrypoint script to run all linters (with optional arguments for individual tools) and share it here for review.