yamllint VS pre-commit

yamllint, as the name suggests, is a linter for YAML files. It checks syntax validity, as well as looking for more-complex errors like key repetition and cosmetic problems such as line length, trailing spaces, indentation etc. This one was indly recommended by yankdevil.

StrictYAML removes features that might be useful for some usecases, such as Node anchors+Refs and Flow Style.

I don't think the cost of an additional standard is worth it in this case.

While YAML has issues, they aren't much of problem if you use a linter, such as yamllint [1].

1. https://github.com/adrienverge/yamllint

On top of the above-mentioned tools, it's also a good idea to use YAML linter such this one or its CLI equivalent, which will validate and cleanup your documents.

yamlfixer automates the fixing of problems reported by yamllint by parsing its output.

repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.0.1 hooks: - id: check-added-large-files - id: check-ast - id: check-builtin-literals - id: check-case-conflict - id: check-docstring-first - id: check-executables-have-shebangs - id: check-json - id: check-merge-conflict - id: check-symlinks - id: check-toml - id: check-vcs-permalinks - id: check-xml - id: check-yaml args: [--allow-multiple-documents] - id: debug-statements - id: detect-aws-credentials args: [--allow-missing-credentials] - id: destroyed-symlinks - id: end-of-file-fixer - id: fix-byte-order-marker - id: fix-encoding-pragma args: [--remove] - id: forbid-new-submodules - id: mixed-line-ending args: [--fix=auto] - id: name-tests-test args: [--django] - id: requirements-txt-fixer - id: trailing-whitespace - repo: local hooks: - id: black name: black entry: poetry run black language: system types: [python] - id: flake8 name: flake8 entry: poetry run flake8 language: system types: [python] - repo: https://github.com/pycqa/isort rev: "5.9.1" hooks: - id: isort args: - --profile - black - --filter-files - repo: https://github.com/adrienverge/yamllint.git rev: v1.26.1 hooks: - id: yamllint args: [-c=.yamllint.yaml] - repo: https://gitlab.com/devopshq/gitlab-ci-linter rev: v1.0.2 hooks: - id: gitlab-ci-linter args: - "--server" - "https://your.gitlab.server" # Need env var GITLAB_PRIVATE_TOKEN with gitlab api read token - repo: https://github.com/commitizen-tools/commitizen rev: v2.17.11 hooks: - id: commitizen stages: [commit-msg] - repo: https://github.com/jumanjihouse/pre-commit-hooks rev: 2.1.5 # or specific git tag hooks: - id: forbid-binary - id: shellcheck - id: shfmt

If you wanted a linter.

Or, run Yamllint externally. I do this, because I have more control: https://github.com/adrienverge/yamllint

You can catch this with yamllint (https://github.com/adrienverge/yamllint):

    % cat countries.yml

Today we are going to look at how to setup Black (a python code formatter) and pre-commit (a package for handling git hooks in python) to automatically format you code on commit.

# See https://pre-commit.com for more information # See https://pre-commit.com/hooks.html for more hooks repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v3.2.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer - id: check-yaml - id: check-toml - id: check-added-large-files - repo: local hooks: - id: tox lint name: tox-validation entry: pdm run tox -e test,lint language: system files: ^src\/.+py$|pyproject.toml|^tests\/.+py$ types_or: [python, toml] pass_filenames: false - id: tox docs name: tox-docs language: system entry: pdm run tox -e docs types_or: [python, rst, toml] files: ^src\/.+py$|pyproject.toml|^docs\/ pass_filenames: false - repo: https://github.com/pdm-project/pdm rev: 2.10.4 # a PDM release exposing the hook hooks: - id: pdm-lock-check - repo: https://github.com/jumanjihouse/pre-commit-hooks rev: 3.0.0 hooks: - id: markdownlint

Pre-commit hooks act as the first line of defense in maintaining code quality, seamlessly integrating with linters and code formatters. They automatically execute these tools each time a developer tries to commit code to the repository, ensuring the code adheres to the project's standards. If the hooks detect issues, the commit is paused until the issues are resolved, guaranteeing that only code meeting quality standards makes it into the repository.

Pre-commit Hooks: Pre-commit is a tool that can be set up to enforce coding rules and standards before you commit your changes to your code repository. This ensures that you can't even check in (commit) code that doesn't meet your standards. This allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.

Ah, fair enough!

On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.

[0]: https://pre-commit.com/

Pre-commit is a framework for managing and maintaining multi-language pre-commit hooks. It supports hooks for various programming languages. Using this framework, you only have to specify a list of hooks you want to run before every commit, and pre-commit handles the installation and execution of those hooks despite your project’s primary language.

You can learn more here: pre-commit.com

Note this includes support for pre-commit.

As a nice next step, you could also add mypy to check your type hints are consistent, and automate running all this via pre-commit hooks set up with… pre-commit.