Skip to content

Linting CI jobs

This page documents the linting-related CI jobs defined in the UIS DevOps ci-templates repository. These jobs are part of our shared AutoDevOps tooling, designed to enforce code quality standards consistently across projects.

The linting jobs perform a range of automated checks to ensure code and configuration files follow established standards and best practices. These checks help teams identify issues early in the development lifecycle - such as formatting errors, style violations, or deprecated patterns — before they reach code review or production.

By integrating these jobs into your CI pipeline, you can enforce consistency across projects, reduce technical debt, and streamline the development process. The templates are designed to be easy to include, configurable where needed, and fully aligned with our broader continuous delivery practices.

Common linting jobs

This section describes the common linting jobs defined in the ci-templates repository. Some jobs are custom-defined within our templates, while others are inherited from GitLab’s built-in Auto DevOps library. These jobs are included in the /auto-devops/common-pipeline.yml template and are used across multiple projects to enforce code quality and consistency.

pre-commit

Runs pre-commit on all files in the repository using the hooks defined in .pre-commit-config.yaml. This tool supports a wide range of language-agnostic and language-specific checks - such as trailing whitespace removal, code formatting, or enforcing commit message conventions.

The job only runs if a .pre-commit-config.yaml file is present in the repository. It is triggered on push and merge request pipelines, but prioritises merge requests when both are present.

By default, the job uses a pre-defined Docker image managed by the UIS DevOps team. You can override the image and version using the following CI variables:

  • PRE_COMMIT_IMAGE_NAME
  • PRE_COMMIT_IMAGE_TAG

To disable this job, set the environment variable PRE_COMMIT_DISABLED to any non-empty value.

This job is included via the /auto-devops/pre-commit.yml template.

detect-non-utf8-files

Checks the encoding of all Git-tracked files to ensure they are using valid character encodings. By default, it allows utf-8 (and us-ascii as its subset), and binary encodings. Files that do not meet these criteria and are not listed in the optional .encoding-allowlist.txt will cause the job to fail.

This helps catch unexpected or incompatible file encodings early in the development lifecycle, which can prevent issues with searching, indexing (e.g., by ElasticSearch), or platform compatibility.

The job uses a lightweight Alpine Linux image and installs necessary utilities (file, git) at runtime. If files with unexpected encodings are found, a warning message is displayed along with a list of those files. Developers can add files with valid but unusual encodings to .encoding-allowlist.txt to avoid future failures.

To disable this job, set the environment variable DETECT_NON_UTF8_FILES_DISABLED to any non-empty value.

Default image and version used can be overridden via:

  • DETECT_NON_UTF8_FILES_IMAGE_NAME
  • DETECT_NON_UTF8_FILES_IMAGE_TAG

Terraform linting jobs

The following jobs are part of the Terraform CI template and are typically used via the /auto-devops/terraform-pipeline.yml template. These jobs help validate, format, lint, and scan Terraform code to catch issues early and enforce consistency across projects.

You can disable any of these jobs by setting the corresponding environment variable in your CI configuration:

  • TERRAFORM_VALIDATE_DISABLED
  • TERRAFORM_FMT_DISABLED
  • TFLINT_DISABLED
  • TRIVY_DISABLED

terraform-validate

Runs terraform validate to ensure that the configuration is syntactically valid and internally consistent. This helps catch common mistakes like typos, missing arguments, etc.

terraform-fmt

Checks formatting of all .tf files using terraform fmt -check. This job enforces consistent code style and formatting across the codebase and fails if any files are not properly formatted.

tflint

Uses TFLint, a powerful linter for Terraform that checks for potential issues, security concerns, and style violations. The job enables most built-in rules by default, with the exception of terraform_standard_module_structure, and supports custom configurations via a .tflint.hcl file.

trivy

Uses Trivy to scan Terraform-managed infrastructure for known misconfigurations and security issues. The scan focuses on infrastructure-as-code files and outputs both human-readable and machine-readable reports (JUnit). Certain rules are excluded by default based on our accepted platform configurations and internal design decisions. Results are shown in merge requests and stored as CI artifacts.