Automated code linting in CI/CD: ESLint, Pylint, golangci-lint

Automated linting in the pipeline: where quality breaks down

Automated linting in most pipelines sits at the end of the run: the build has passed, tests have reported, the image has been pushed to the registry — and only then does the code check run in the pipeline.

Feedback arrives after several minutes of waiting, the log is long, and the task has already been moved on. The build bottleneck turns out not to be compilation but the fact that the signal about a problem arrives late and stops nothing.

This is why errors are found late: an unused variable, a swallowed exception, a contract mismatch between modules surface during review or on the staging environment.

At that point, the fix goes through the entire chain — branch, rerun, re-approval — rather than a single line that the author still keeps in mind. The cost of fixing grows with every step at which it was caught.

Manual comments in review are almost always about the same things: formatting, naming, import order, forgotten debug output. The reviewer goes through style instead of logic, and a debate about preferences takes the place of discussing architecture.

Some comments never arrive at all — the rule is not recorded anywhere, and everything repeats in the next branch.

The cause is not discipline but configuration.

The linter (ESLint, Pylint, or golangci-lint — depending on the project stack) runs across the entire tree, thousands of warnings hang over legacy code, the severity level is set to warning instead of error — and no one notices the tenth out of a hundred.

Let's look at how this is addressed: moving the check to the start of the run, a strict level for new changes, and a separate mode for historical code.

What automated linting delivers: effect on the build

A linter in the pipeline has an effect not on its own but through which errors stop reaching review and release. A configured rule set stops the build at the static analysis stage — in seconds, not an hour later in the test environment.

Early error diagnostics shift the cost of fixing: a typo in a variable name is caught before the code leaves the developer's branch.

Build time does not increase: checks run in parallel with tests and cache the result by file hash, so a rerun over unchanged modules takes just seconds.

The main gain is elsewhere — the failure moves from the integration test stage to the earliest step, and the release pipeline stops idling on restarts.

The share of failures on the release branch drops because some defects simply do not reach it.

Naming conflicts, unhandled exceptions, dead code, and deviations from conventions are cut off when changes are submitted — a class of errors that previously surfaced during acceptance or already in production.

The load on review decreases because the reviewer stops being a formatting filter. Debates about line length, import order, and semicolons disappear from comments: rules are set in configuration such as ESLint, Pylint, or golangci-lint and applied automatically.

A unified code style stops being a matter of verbal agreements — a new engineer gets it straight from the repository.

Code check formats: locally, in the build, on a server

The same check can trigger at four points in the process, and these are not mutually exclusive options: the practice is to choose the mandatory point and add cheap safeguards to it.

Below — by the columns "when it fits" and "limitations", to compare the mode with repository size and release cadence.

The working combination is usually this: pre-commit checks on changed files plus a mandatory quality gate in the build.

The editor check speeds up edits but is not a threshold, while a dedicated check server provides full coverage across the entire tree and charts of violations over time.

Rules for a monorepo should be kept in a shared config at the root, and exceptions described at the package level. Otherwise the gate starts blocking other people's changes, and after a couple of weeks it is disabled entirely — along with all the useful checks.

How we structure checks: order of work

We start the audit not with configuration but with measurement: how many comments each linter produces on the current codebase and which rules trigger en masse.

If a strict set is enabled immediately, the build turns red on the very first change — and the team learns to bypass the check instead of fixing code. So we move from a picture of the real state to gradual tightening.

1. Codebase audit. We calculate volume by language and rule triggers for ESLint, Pylint, and golangci-lint on the current branch. The output is a list of mass violations and files that we fix before enabling strict mode.

2. Rule set. We divide rules into three groups: those catching real defects — enabled immediately; style rules — as edits are made; controversial ones — into exceptions with a note of the reason. The configuration stays readable rather than a dump.

3. Enabling strict rules. First report mode, then group by group we convert to errors — by directories and modules, so as not to block the entire team at once.

4. Running in CI/CD. The linter checks changed lines rather than the entire repository: the build does not get longer, but a new violation does not pass. A local run before submission gives the same check in seconds.

5. Validation on real changes. We run it on the stream of ordinary tasks: we look at the false positive rate, check time, and how many blocks were removed manually. Rules that get in the way without benefit are fixed before handover.

6. Handover of the policy. We hand over a document: which rules are enabled and why, how to add an exception, who approves configuration changes. We walk through it on the team's code — that way the policy gets read rather than filed away.

What the team receives after the checks are implemented

Implementing checks ends not with a "green" build but with a set of artifacts that the team maintains on its own from then on.

Configurations and shared rule sets live in the repository next to the code, so a new service connects to automated linting by copying rather than negotiating with the infrastructure team. Below is what exactly remains in your hands.

• Rule configurations for each language with comments: what the rule catches, why it is enabled, how to formalize a false positive.
• Shared sets for repositories: a base profile as a mandatory minimum and pluggable modules for services, interface, and infrastructure descriptions. Inheritance instead of copying — the rule changes in one place.
• Check launch scheme: a pre-commit hook on changed files, the full set on branch merge as a blocking step, a nightly run across the entire codebase — new rules do not suddenly break old files.
• Exception procedure: a suppression file with justification, owner, and review date for each entry. Temporary disabling of a rule differs from permanent and is visible in the report.
• Code quality documentation: how to add or downgrade a rule, where to view the report, what to do when the build is red.
• Policy for responding to violations: what gets fixed in the current task, what becomes a separate item, when escalation is involved. A rule that everyone bypasses is honestly disabled or converted to a warning.
• Metrics set: share of checked paths, number of suppressions per repository, run time — these show where the set started getting in the way rather than helping.

After a month of support, such a kit allows rules to be changed without us, and reviewing violations becomes part of ordinary review.

Case study: a unified quality gate in a monorepo

A monorepo with several dozen packages: some rules lived in local configurations, others in separate repositories connected as dependencies. The sets diverged — ESLint, Pylint, and golangci-lint ran with different severity levels. The same fragment passed the check in one package and broke the build in the neighboring one.

The cost of the divergence showed up in rollbacks: a change looked green in its own branch, but after merging it broke another module — and that was dealt with already at release.

Finding the cause took hours because it turned out to be in a rule disabled locally and unnoticed by others.

How the unified gate was set up

All rules moved into a shared configuration package that is connected in each package and updated centrally. A single entry point appeared in CI: first fast checks of changed files, then a run over affected packages, separately — blocking and informational levels. Rule changes go through review like ordinary code.

Result: failures for reasons caught by static analysis dropped by about three times, and discrepancies between teams disappeared from regular work. Branch check time stays within a few minutes thanks to running only changed packages. A new package connects the gate with one line and immediately gets the current rule set.

How a check in the build differs from a check in the editor

A local check in the editor answers the question "did I make a mistake right now": the linter triggers on file save, highlights the problem in fractions of a second, and provides the feedback speed for which it is installed.

But it offers no guarantees — the extension may be disabled, the rule set may differ from the team's, and some files in that session may not have been opened at all.

The mandatory gate in the build is the only place where a rule becomes mandatory. The check runs on the same commit that goes to the main branch, and if there is a violation, the merge is blocked. Here the project is also analyzed as a whole, including code that no one has touched by hand.

The division of responsibilities follows simply: locally — fast feedback on changed files, in the pipeline — the full rule set and the final decision. Feedback speed is provided by the editor, not the build, so expensive checks do not need to be dragged into the local loop.

Duplicating rules breaks the scheme. If the configuration in the editor and in the gate live separately, the developer learns about a violation only at the merge stage, and rule versions diverge.

That is why the set is connected from a single file that both ESLint-like tools and the build step read: locally — warnings, in the gate — an error.

Technical doubts: questions about rules and maintenance

Before enabling checks in the build, the same doubts arise: what to do with long-written code, whether the run will start taking longer, and who will edit the rules after the team changes. Below is a brief look at how this is solved in practice.

Will automated linting slow down the build?

Checks run in parallel with tests and artifact builds, so seconds, not minutes, are added to the total time. The main delay is re-parsing the dependency tree, which is removed by caching between runs: after warm-up, the linter costs about the same as installing dependencies. For large changes, we check only affected files, leaving the full pass for the nightly run.

Who will maintain the rule set after the project handover?

The config lives in the repository next to the code and is changed by an ordinary merge request — with review by a second engineer and a history of who enabled a rule and why.

We hand over documentation: the purpose of each rule, which failure it appeared because of, how to add your own and how to remove noise.

Tightening happens in portions: every two weeks we enable one or two groups of rules, look at the share of build failures and roll back if there are more warnings than real defects.

Let's discuss the task: what to know before the start

An estimate is accurate when we see the project, not a two-line description of it. The first conversation takes 30–40 minutes and is to the point: we go through repositories, current checks, and what prevents them from working. Below are the inputs after which we return with an estimate and work plan.

• repositories: how many there are, what languages the code is in, whether there are shared libraries with their own rules;
• current checks: which linters are already connected, with which rule sets, what breaks and how often;
• build: where the pipeline runs, at which stage checks are launched, how long a full run takes;
• quality policy: what blocks a merge, what remains a warning, and who receives notifications;
• access: repository rights, build agents, ability to run checks on every merge request;
• pain points: which errors surface latest and in which areas changes are most often rolled back;
• on your side: who makes decisions about rules and who stays in touch on infrastructure.

We name the team composition right away: a build and checks engineer, an infrastructure engineer, plus the person who maintains documentation and hands over rules to your team.

After the conversation, we return with an estimate and work plan — the order of stages, what we enable first, how we make sure that checks do not slow down the build and do not get in the way of work. If it is clear that some tasks can be handled by your own forces, we will say so directly.