Are you over 18 and want to see adult content?
More Annotations
![A complete backup of softballbats-sale.com](https://www.archivebay.com/archive5/images/635b57ca-5ec5-4478-be0c-c6ff7dba2dae.png)
A complete backup of softballbats-sale.com
Are you over 18 and want to see adult content?
![A complete backup of pharmacynews.com.au](https://www.archivebay.com/archive5/images/7674c0e5-8dd3-4236-ab31-4b8902331bfc.png)
A complete backup of pharmacynews.com.au
Are you over 18 and want to see adult content?
![A complete backup of in-berlin-brandenburg.com](https://www.archivebay.com/archive5/images/9582539e-bd91-477f-91f7-618f2690a0a9.png)
A complete backup of in-berlin-brandenburg.com
Are you over 18 and want to see adult content?
![A complete backup of pandoracanadajewelrycharms.ca](https://www.archivebay.com/archive5/images/8bd41b71-5a19-4cd9-8e80-73205beeaf36.png)
A complete backup of pandoracanadajewelrycharms.ca
Are you over 18 and want to see adult content?
Favourite Annotations
![A complete backup of criswellchevrolet.com](https://www.archivebay.com/archive/eb16e83c-db8f-4d6b-a4a4-f4eec4f5723b.png)
A complete backup of criswellchevrolet.com
Are you over 18 and want to see adult content?
![A complete backup of husseinandwebber.com](https://www.archivebay.com/archive/c0a72afb-c8f2-4577-8f2d-23c8bef8d0e8.png)
A complete backup of husseinandwebber.com
Are you over 18 and want to see adult content?
Text
PRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant filesPRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant filesPRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant filesPRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant filesPRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant filesPRE-COMMIT
pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exitnonzero on
PRE-COMMIT
end-of-file-fixer - Ensures that a file is either empty, or ends with one newline. file-contents-sorter - Sort the lines in specified files (defaults to alphabetical). You must provide list of target files as input in your .pre-commit-config.yaml file. fix-byte-order-marker - removes UTF-8 byte order marker.PRE-COMMIT
{ "https://github.com/pre-commit/pre-commit-hooks": [ { "id": "check-added-large-files", "name": "Check for added large files", "description": "Prevent giant files* Documentation
* Supported hooks
* Demo
* Download on GitHubPRE-COMMIT
A framework for managing and maintaining multi-language pre-commithooks.
Introduction Installation Adding plugins Usage Creating new hooks Command line interface Advanced features ContributingINTRODUCTION ¶
Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial stylenitpicks.
As we created more libraries and projects we recognized that sharing our pre-commit hooks across projects is painful. We copied and pasted unwieldy bash scripts from project to project and had to manually change the hooks to work for different project structures. We believe that you should always use the best industry standard linters. Some of the best linters are written in languages that you do not use in your project or have installed on your machine. For example scss-lint is a linter for SCSS written in Ruby. If you’re writing a project in node you should be able to use scss-lint as a pre-commit hook without adding a Gemfile to your project or understanding how to get scss-lint installed. We built pre-commit to solve our hook issues. It is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit is specifically designed to not require root access. If one of your developers doesn’t have node installed but modifies a JavaScript file, pre-commit automatically handles downloading and building node to run eslint without root.INSTALLATION ¶
Before you can run hooks, you need to have the pre-commit packagemanager installed.
Using pip:
pip install pre-commit Non-administrative installation: * _to upgrade: run again, to uninstall: pass uninstall to python_ * _does not work on platforms without symlink support (windows)_ curl https://pre-commit.com/install-local.py | python - In a python project, add the following to your requirements.txt (or requirements-dev.txt):pre-commit
As a 0-dependency zipapp:
* locate and download the .pyz file from the github releases * run python pre-commit-#.#.#.pyz ... in place of pre-commit ...Using homebrew :
brew install pre-commit Using conda (via conda-forge):
conda install -c conda-forge pre-commitQUICK START ¶
1. INSTALL PRE-COMMIT ¶ * follow the install instructions above * pre-commit --version should show you what version you're using $ pre-commit --versionpre-commit 2.13.0
2. ADD A PRE-COMMIT CONFIGURATION ¶ * create a file named .pre-commit-config.yaml * you can generate a very basic configuration using pre-commitsample-config
* the full set of options for the configuration are listed below * this example uses a formatter for python code, however pre-commit works for any programming language * other supported hooks are availablerepos:
- repo: https://github.com/pre-commit/pre-commit-hooksrev: v2.3.0
hooks:
- id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace - repo: https://github.com/psf/blackrev: 19.3b0
hooks:
- id: black
3. INSTALL THE GIT HOOK SCRIPTS ¶ * run pre-commit install to set up the git hook scripts $ pre-commit install pre-commit installed at .git/hooks/pre-commit * now pre-commit will run automatically on git commit! 4. (OPTIONAL) RUN AGAINST ALL THE FILES ¶ * it's usually a good idea to run the hooks against all of the files when adding new hooks (usually pre-commit will only run on the changed files during git hooks) $ pre-commit run --all-files Initializing environment for https://github.com/pre-commit/pre-commit-hooks. Initializing environment for https://github.com/psf/black. Installing environment for https://github.com/pre-commit/pre-commit-hooks. Once installed this environment will be reused. This may take a few minutes... Installing environment for https://github.com/psf/black. Once installed this environment will be reused. This may take a few minutes... Check Yaml...............................................................Passed Fix End of Files.........................................................Passed Trim Trailing Whitespace.................................................Failed - hook id: trailing-whitespace- exit code: 1
Files were modified by this hook. Additional output:Fixing sample.py
black....................................................................Passed * oops! looks like I had some trailing whitespace * consider running that in CI too ADDING PRE-COMMIT PLUGINS TO YOUR PROJECT ¶ Once you have pre-commit installed, adding pre-commit plugins to your project is done with the .pre-commit-config.yaml configuration file. Add a file called .pre-commit-config.yaml to the root of your project. The pre-commit config file describes what repositories and hooks areinstalled.
.PRE-COMMIT-CONFIG.YAML - TOP LEVEL ¶ _new in 1.0.0_: The default configuration file top-level was changed from a list to a map. If you're using an old version of pre-commit, the top-level list is the same as the value of repos. If you'd like to migrate to the new configuration format, run pre-commit migrate-config to automatically migrate your configuration.repos
A list of repository mappings. default_language_version (optional: default {}) a mapping from language to the default language_version that should be used for that language. This will only override individual hooks that do not set language_version. For example to use python3.7 for language: python hooks: default_language_version:python: python3.7
_new in 1.14.0_
default_stages
(optional: default (all stages)) a configuration-wide default for the stages property of hooks. This will only override individual hooks that do not set stages.For example:
default_stages:
_new in 1.14.0_
files
(optional: default '') global file include pattern. _new in 1.21.0_.exclude
(optional: default ^$) global file exclude pattern. _new in 1.1.0_.fail_fast
(optional: default false) set to true to have pre-commit stop running hooks after the first failure. _new in 1.1.0_. minimum_pre_commit_version (optional: default '0') require a minimum version of pre-commit. _newin 1.15.0_.
A sample top-level:
exclude: '^$'
fail_fast: false
repos:
- ...
.PRE-COMMIT-CONFIG.YAML - REPOS ¶ The repository mapping tells pre-commit where to get the code for thehook from.
repo
the repository url to git clone fromrev
the revision or tag to clone at. _new in 1.7.0_: previously shahooks
A list of hook mappings. A sample repository:repos:
- repo: https://github.com/pre-commit/pre-commit-hooksrev: v1.2.3
hooks:
- ...
.PRE-COMMIT-CONFIG.YAML - HOOKS ¶ The hook mapping configures which hook from the repository is used and allows for customization. All optional keys will receive their default from the repository's configuration.id
which hook from the repository to use.alias
(optional) allows the hook to be referenced using an additional id when using pre-commit runname
(optional) override the name of the hook - shown during hookexecution.
language_version
(optional) override the language version for the hook. See OverridingLanguage Version.
files
(optional) override the default pattern for files to run on.exclude
(optional) file exclude pattern.types
(optional) override the default file types to run on (AND). See Filtering files with types.types_or
(optional) override the default file types to run on (OR). See Filtering files with types. _new in 2.9.0_.exclude_types
(optional) file types to exclude.args
(optional) list of additional parameters to pass to the hook.stages
(optional) confines the hook to the commit, merge-commit, push, prepare-commit-msg, commit-msg, post-checkout, post-commit, post-merge, or manual stage. See Confining hooks to run at certainstages.
additional_dependencies (optional) a list of dependencies that will be installed in the environment where this hook gets run. One useful application is to install plugins for hooks such as eslint.always_run
(optional) if true, this hook will run even if there are no matchingfiles.
verbose
(optional) if true, forces the output of the hook to be printed even when the hook passes. _new in 1.6.0_.log_file
(optional) if present, the hook output will additionally be written to a file when the hook fails or verbose is true. One example of a complete configuration:repos:
- repo: https://github.com/pre-commit/pre-commit-hooksrev: v1.2.3
hooks:
- id: trailing-whitespace This configuration says to download the pre-commit-hooks project and run its trailing-whitespace hook. UPDATING HOOKS AUTOMATICALLY ¶ You can update your hooks to the latest version automatically by running pre-commit autoupdate. By default, this will bring the hooks to the latest tag on the default branch.USAGE ¶
Run pre-commit install to install pre-commit into your git hooks. pre-commit will now run on every commit. Every time you clone a project using pre-commit running pre-commit install should always be the first thing you do. If you want to manually run all pre-commit hooks on a repository, run pre-commit run --all-files. To run individual hooks use pre-commit run.
The first time pre-commit runs on a file it will automatically download, install, and run the hook. Note that running a hook for the first time may be slow. For example: If the machine does not have node installed, pre-commit will download and build a copy of node. $ pre-commit install pre-commit installed at /home/asottile/workspace/pytest/.git/hooks/pre-commit $ git commit -m "Add super awesome feature" black....................................................................Passed blacken-docs.........................................(no files to check)Skipped Trim Trailing Whitespace.................................................Passed Fix End of Files.........................................................Passed Check Yaml...........................................(no files to check)Skipped Debug Statements (Python)................................................Passed Flake8...................................................................Passed Reorder python imports...................................................Passed pyupgrade................................................................Passed rst ``code`` is two backticks........................(no files to check)Skipped rst..................................................(no files to check)Skipped changelog filenames..................................(no files to check)Skipped Add super awesome feature 1 file changed, 1 insertion(+) CREATING NEW HOOKS ¶ pre-commit currently supports hooks written in many languages. As long as your git repo is an installable package (gem, npm, pypi, etc.) or exposes an executable, it can be used with pre-commit. Each git repo can support as many languages/hooks as you want. The hook must exit nonzero on failure or modify files. A git repo containing pre-commit plugins must contain a .pre-commit-hooks.yaml file that tells pre-commit: id
the id of the hook - used in pre-commit-config.yaml.name
the name of the hook - shown during hook execution.entry
the entry point - the executable to run. entry can also contain arguments that will not be overridden such as entry: autopep8 -i.language
the language of the hook - tells pre-commit how to install the hook.files
(optional: default '') the pattern of files to run on.exclude
(optional: default ^$) exclude files that were matched by files.types
(optional: default ) list of file types to run on (AND). See Filtering files with types.types_or
(optional: default ) list of file types to run on (OR). See Filtering files with types. _new in 2.9.0_.exclude_types
(optional: default ) the pattern of files to exclude.always_run
(optional: default false) if true this hook will run even if there areno matching files.
verbose
(optional) if true, forces the output of the hook to be printed even when the hook passes. _new in 1.6.0_.pass_filenames
(optional: default true) if false no filenames will be passed to thehook.
require_serial
(optional: default false) if true this hook will execute using a single process instead of in parallel. _new in 1.13.0_.description
(optional: default '') description of the hook. used for metadatapurposes only.
language_version
(optional: default default) see Overriding language version. minimum_pre_commit_version (optional: default '0') allows one to indicate a minimum compatiblepre-commit version.
args
(optional: default ) list of additional parameters to pass to thehook.
stages
(optional: default (all stages)) confines the hook to the commit, merge-commit, push, prepare-commit-msg, commit-msg, post-checkout, post-commit, post-merge, or manual stage. See Confining hooks to runat certain stages.
For example:
- id: trailing-whitespace name: Trim Trailing Whitespace description: This hook trims trailing whitespace. entry: trailing-whitespace-fixerlanguage: python
types:
DEVELOPING HOOKS INTERACTIVELY ¶ Since the repo property of .pre-commit-config.yaml can refer to anything that git clone ... understands, it's often useful to point it at a local directory while developing hooks. pre-commit try-repo streamlines this process by enabling a quick way to try out a repository. Here's how one might work interactively: _note_: you may need to provide --commit-msg-filename when using this command with hook types prepare-commit-msg and commit-msg. _new in 1.14.0_: a commit is no longer necessary to try-repo on a local directory. pre-commit will clone any tracked uncommittedchanges.
~/work/hook-repo $ git checkout origin/master -b feature # ... make some changes # new in 1.14.0: a commit is no longer necessary for `try-repo` # In another terminal or tab ~/work/other-repo $ pre-commit try-repo ../hook-repo foo --verbose --all-files ===============================================================================Using config:
===============================================================================repos:
- repo: ../hook-repo rev: 84f01ac09fcd8610824f9626a590b83cfae9bcbdhooks:
- id: foo
=============================================================================== Initializing environment for ../hook-repo. Foo......................................................................Passed- hook id: foo
- duration: 0.02s
Hello from foo hook! SUPPORTED LANGUAGES ¶* conda
* coursier
* docker
* docker_image
* dotnet
* fail
* golang
* node
* perl
* python
* python_venv
* r
* ruby
* rust
* swift
* pygrep
* script
* system
CONDA ¶
_new in 1.21.0_
The hook repository must contain an environment.yml file which will be used via conda env create --file environment.yml ... to create theenvironment.
The conda language also supports additional_dependencies and will pass any of the values directly into conda install. This language can therefore be used with local hooks. SUPPORT: conda hooks work as long as there is a system-installed conda binary (such as miniconda ). It has been tested on linux, macOS, and windows.COURSIER ¶
_new in 2.8.0_
The hook repository must have a .pre-commit-channel folder and that folder must contain the coursier application descriptors for the hook to install. For configuring coursier hooks, your entry should correspond to an executable installed from the repository's .pre-commit-channel folder. SUPPORT: coursier hooks are known to work on any system which has the cs package manager installed. The specific coursier applications you install may depend on various versions of the JVM, consult the hooks' documentation for clarification. It has been tested on linux.DOCKER ¶
The hook repository must have a Dockerfile. It will be installed viadocker build ..
Running Docker hooks requires a running Docker engine on your host. For configuring Docker hooks, your entry should correspond to an executable inside the Docker container, and will be used to override the default container entrypoint. Your Docker CMD will not run when pre-commit passes a file list as arguments to the run container command. Docker allows you to use any language that's not supported by pre-commit as a builtin. pre-commit will automatically mount the repository source as a volume using -v $PWD:/src:rw,Z and set the working directory using --workdir/src.
SUPPORT: docker hooks are known to work on any system which has a working docker executable. It has been tested on linux and macOS. Hooks that are run via boot2docker are known to be unable to make modifications to files.See this repository
for an
example Docker-based hook.DOCKER_IMAGE ¶
A more lightweight approach to docker hooks. The docker_image "language" uses existing docker images to provide hook executables. docker_image hooks can be conveniently configured as local hooks. The entry specifies the docker tag to use. If an image has an ENTRYPOINT defined, nothing special is needed to hook up the executable. If the container does not specify an ENTRYPOINT or you want to change the entrypoint you can specify it as well in yourentry.
For example:
- id: dockerfile-provides-entrypointname: ...
language: docker_image entry: my.registry.example.com/docker-image-1:latest - id: dockerfile-no-entrypoint-1name: ...
language: docker_image entry: --entrypoint my-exe my.registry.example.com/docker-image-2:latest # Alternative equivalent solution - id: dockerfile-no-entrypoint-2name: ...
language: docker_image entry: my.registry.example.com/docker-image-3:latest my-exeDOTNET ¶
_new in 2.8.0_
dotnet hooks are installed using the system installation of the dotnetCLI.
Hook repositories must contain a dotnet CLI tool which can be packed and installed as per this example. The entry should match an executable created by building the repository. Additional dependencies are not currently supported. SUPPORT: dotnet hooks are known to work on any system which has the dotnet CLI installed. It has been tested on linux and windows.FAIL ¶
_new in 1.11.0_
A lightweight language to forbid files by filename. The fail language is especially useful for local hooks. The entry will be printed when the hook fails. It is suggested to provide a brief description for name and more verbose fix instructionsin entry.
Here's an example which prevents any file except those ending with .rst from being added to the changelog directory:- repo: local
hooks:
- id: changelogs-rst name: changelogs must be rst entry: changelog filenames must end in .rstlanguage: fail
files: 'changelog/.*(?GOLANG ¶The hook repository must contain go source code. It will be installed via go get ./.... pre-commit will create an isolated GOPATH for each hook and the entry should match an executable which will get installed into the GOPATH's bin directory. SUPPORT: golang hooks are known to work on any system which has go installed. It has been tested on linux, macOS, and windows.NODE ¶
The hook repository must have a package.json. It will be installed via npm install .. The installed package will provide an executable that will match the entry – usually through bin in package.json. SUPPORT: node hooks work without any system-level dependencies. It has been tested on linux and macOS and _may_ work under cygwin. _new in 1.5.0_: windows is now supported for node hooks. Currently python3 only due to a bug in cpython.
PERL ¶
_new in 2.1.0_
Perl hooks are installed using the system installation of cpan, the CPAN package
installer that comes with Perl. Hook repositories must have something that cpan supports, typically Makefile.PL or Build.PL, which it uses to install an executable to use in the entry definition for your hook. The repository will be installed via cpan -T . (with the installed files stored in your pre-commit cache, not polluting other Perl installations). When specifying additional_dependencies for Perl, you can use any of the install argument formats understood by cpan.
SUPPORT: Perl hooks currently require a pre-existing Perl installation, including the cpan tool in PATH. It has been tested on linux, macOS, and Windows.PYTHON ¶
The hook repository must be installable via pip install . (usually by either setup.py or pyproject.toml). The installed package will provide an executable that will match the entry – usually through console_scripts or scripts in setup.py. SUPPORT: python hooks work without any system-level dependencies. It has been tested on linux, macOS, windows, and cygwin.PYTHON_VENV ¶
_new in 1.9.0_
_new in 2.4.0_: The python_venv language is now an alias to python since virtualenv>=20 creates equivalently structured environments. Previously, this language created environments using the venvmodule.
This language will be removed eventually so it is suggested to usepython instead.
SUPPORT: python hooks work without any system-level dependencies. It has been tested on linux, macOS, windows, and cygwin.R ¶
_new in 2.11.0_
This hook repository must have a renv.lock file that will be restored with renv::restore()on hook
installation. If the repository is an R package (i.e. has Type: Package in DESCRIPTION), it is installed. The supported syntax in entry is Rscript -e {expression} or Rscript path/relative/to/hook/root. The R Startup process is skipped (emulating --vanilla), as all configuration should be exposed via args for maximal transparency and portability. When specifying additional_dependencies for R, you can use any of the install argument formats understood by renv::install().
SUPPORT: r hooks work as long as R is installed and on PATH. It has been tested on linux, macOS, andwindows.
RUBY ¶
The hook repository must have a *.gemspec. It will be installed via gem build *.gemspec && gem install *.gem. The installed package will produce an executable that will match the entry – usually through executables in your gemspec. SUPPORT: ruby hooks work without any system-level dependencies. It has been tested on linux and macOS and _may_ work under cygwin.RUST ¶
_new in 1.10.0_
Rust hooks are installed using the system installation of Cargo , Rust's official package manager. Hook repositories must have a Cargo.toml file which produces at leastone binary (example
), whose
name should match the entry definition for your hook. The repo will be installed via cargo install --bins (with the binaries stored in your pre-commit cache, not polluting your user-level Cargo installations). When specifying additional_dependencies for Rust, you can use the syntax {package_name}:{package_version} to specify a new library dependency (used to build _your_ hook repo), or the special syntax cli:{package_name}:{package_version} for a CLI dependency (built separately, with binaries made available for use by hooks). SUPPORT: Rust hooks currently require a pre-existing Rust installation. It has been tested on linux, Windows, and macOS.SWIFT ¶
The hook repository must have a Package.swift. It will be installed via swift build -c release. The entry should match an executable created by building the repository. SUPPORT: swift hooks are known to work on any system which has swift installed. It has been tested on linux and macOS.PYGREP ¶
_new in 1.2.0_
A cross-platform python implementation of grep – pygrep hooks are a quick way to write a simple hook which prevents commits by file matching. Specify the regex as the entry. The entry may be any python regular expression. For case insensitive regexes you can apply the (?i) flag as the start of your entry, or use args: . _new in 1.8.0_: For multiline matches, use args: . _new in 2.8.0_: To require all files to match, use args: . SUPPORT: pygrep hooks are supported on all platforms which pre-commitruns on.
SCRIPT ¶
Script hooks provide a way to write simple scripts which validate files. The entry should be a path relative to the root of the hookrepository.
This hook type will not be given a virtual environment to work with – if it needs additional dependencies the consumer must install themmanually.
SUPPORT: the support of script hooks depend on the scripts themselves.SYSTEM ¶
System hooks provide a way to write hooks for system-level executables which don't have a supported language above (or have special environment requirements that don't allow them to run in isolationsuch as pylint).
This hook type will not be given a virtual environment to work with – if it needs additional dependencies the consumer must install themmanually.
SUPPORT: the support of system hooks depend on the executables. COMMAND LINE INTERFACE ¶ All pre-commit commands take the following options: * --color {auto,always,never}: whether to use color in output. Defaults to auto. _new in 1.18.0_: can be overridden by using PRE_COMMIT_COLOR={auto,always,never} or disabled using TERM=dumb. * -c CONFIG, --config CONFIG: path to alternate config file * -h, --help: show help and available options. _new in 2.8.0_: pre-commit now exits with more specific codes: * 1: a detected / expected error * 3: an unexpected error * 130: the process was interrupted by ^C PRE-COMMIT AUTOUPDATE ¶ Auto-update pre-commit config to the latest repos' versions.Options:
* --bleeding-edge: update to the bleeding edge of the default branch instead of the latest tagged version (the default behaviour). * --freeze: _new in 1.21.0_: Store "frozen" hashes in rev instead oftag names.
* --repo REPO: _new in 1.4.1_: Only update this repository. _new in 1.7.0_: This option may be specified multiple times. Here are some sample invocations using this .pre-commit-config.yaml:repos:
- repo: https://github.com/pre-commit/pre-commit-hooksrev: v2.1.0
hooks:
- id: trailing-whitespace - repo: https://github.com/asottile/pyupgraderev: v1.25.0
hooks:
- id: pyupgradeargs:
$ : default: update to latest tag on default branch $ pre-commit autoupdate # by default: pick tags Updating https://github.com/pre-commit/pre-commit-hooks ... updating v2.1.0 -> v2.4.0. Updating https://github.com/asottile/pyupgrade ... updating v1.25.0 -> v1.25.2. $ grep rev: .pre-commit-config.yamlrev: v2.4.0
rev: v1.25.2
$ : update a specific repository to the latest revision of the default branch $ pre-commit autoupdate --bleeding-edge --repo https://github.com/pre-commit/pre-commit-hooks Updating https://github.com/pre-commit/pre-commit-hooks ... updating v2.1.0 -> 5df1a4bf6f04a1ed3a643167b38d502575e29aef. $ grep rev: .pre-commit-config.yaml rev: 5df1a4bf6f04a1ed3a643167b38d502575e29aefrev: v1.25.0
$ : update to frozen versions $ pre-commit autoupdate --freeze Updating https://github.com/pre-commit/pre-commit-hooks ... updating v2.1.0 -> v2.4.0 (frozen). Updating https://github.com/asottile/pyupgrade ... updating v1.25.0 -> v1.25.2 (frozen). $ grep rev: .pre-commit-config.yaml rev: 0161422b4e09b47536ea13f49e786eb3616fe0d7 # frozen: v2.4.0 rev: 34a269fd7650d264e4de7603157c10d0a9bb8211 # frozen: v1.25.2 PRE-COMMIT CLEAN ¶ Clean out cached pre-commit files. Options: (no additional options)PRE-COMMIT GC ¶
_new in 1.14.0_
Clean unused cached repos. pre-commit keeps a cache of installed hook repositories which grows over time. This command can be run periodically to clean out unused repos from the cache directory. Options: (no additional options) PRE-COMMIT INIT-TEMPLATEDIR DIRECTORY ¶_new in 1.18.0_
Install hook script in a directory intended for use with git configinit.templateDir.
Options:
* -t
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge},--hook-type
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge}: which hook type to install. Some example useful invocations: git config --global init.templateDir ~/.git-template pre-commit init-templatedir ~/.git-template For Windows cmd.exe use %HOMEPATH% instead of ~: pre-commit init-templatedir %HOMEPATH%\.git-template For Windows PowerShell use $HOME instead of ~: pre-commit init-templatedir $HOME\.git-template Now whenever a repository is cloned or created, it will have the hooksset up already!
PRE-COMMIT INSTALL ¶ Install the pre-commit script.Options:
* -f, --overwrite: Replace any existing git hooks with thepre-commit script.
* --install-hooks: Also install environments for all available hooks now (rather than when they are first executed). See pre-commitinstall-hooks.
* -t
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge},--hook-type
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge}: Specify which hook type to install. * --allow-missing-config: Hook scripts will permit a missingconfiguration file.
Some example useful invocations: * pre-commit install: Default invocation. Installs the pre-commit script alongside any existing git hooks. * pre-commit install --install-hooks --overwrite: Idempotently replaces existing git hook scripts with pre-commit, and also installshook environments.
PRE-COMMIT INSTALL-HOOKS ¶ Install all missing environments for the available hooks. Unless this command or install --install-hooks is executed, each hook's environment is created the first time the hook is called. Each hook is initialized in a separate environment appropriate to the language the hook is written in. See supported languages. This command does not install the pre-commit script. To install the script along with the hook environments in one command, use pre-commit install --install-hooks. Options: (no additional options) PRE-COMMIT MIGRATE-CONFIG ¶_new in 1.0.0_
Migrate list configuration to the new map configuration format. Options: (no additional options)PRE-COMMIT RUN ¶
Run hooks.
Options:
* : specify a single hook-id to run only that hook. * -a, --all-files: run on all the files in the repo. * --files : specific filenames to run hooks on. * --from-ref FROM_REF + --to-ref TO_REF: run against the files changed between FROM_REF...TO_REF in git. * _new in 2.2.0_: prior to 2.2.0 the arguments were --source and--origin.
* --hook-stage STAGE: select a stage to run. * --show-diff-on-failure: when hooks fail, run git diff directlyafterward.
* -v, --verbose: produce hook output independent of success. Includehook ids in output.
Some example useful invocations: * pre-commit run: this is what pre-commit runs by default when committing. This will run all hooks against currently staged files. * pre-commit run --all-files: run all the hooks against all the files. This is a useful invocation if you are using pre-commit in CI. * pre-commit run flake8: run the flake8 hook against all stagedfiles.
* git ls-files -- '*.py' | xargs pre-commit run --files: run all hooks against all *.py files in the repository. * pre-commit run --from-ref HEAD^^^ --to-ref HEAD: run against the files that have changed between HEAD^^^ and HEAD. This form is useful when leveraged in a pre-receive hook. PRE-COMMIT SAMPLE-CONFIG ¶ Produce a sample .pre-commit-config.yaml. Options: (no additional options) PRE-COMMIT TRY-REPO REPO ¶_new in 1.3.0_
Try the hooks in a repository, useful for developing new hooks. try-repo can also be used for testing out a repository before adding it to your configuration. try-repo prints a configuration it generates based on the remote hook repository before running the hooks.Options:
* REPO: required clonable hooks repository. Can be a local path ondisk.
* --ref REF: Manually select a ref to run against, otherwise the HEAD revision will be used. * pre-commit try-repo also supports all available options forpre-commit run.
Some example useful invocations: * pre-commit try-repo https://github.com/pre-commit/pre-commit-hooks: runs all the hooks in the latest revision of pre-commit/pre-commit-hooks. * pre-commit try-repo ../path/to/repo: run all the hooks in arepository on disk.
* pre-commit try-repo ../pre-commit-hooks flake8: run only the flake8 hook configured in a local ../pre-commit-hooks repository. * See pre-commit run for more useful run invocations which are also supported by pre-commit try-repo. PRE-COMMIT UNINSTALL ¶ Uninstall the pre-commit script.Options:
* -t
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge},--hook-type
{pre-commit,pre-merge-commit,pre-push,prepare-commit-msg,commit-msg,post-checkout,post-commit,post-merge}: which hook type to uninstall. ADVANCED FEATURES ¶ RUNNING IN MIGRATION MODE ¶ By default, if you have existing hooks pre-commit install will install in a migration mode which runs both your existing hooks and hooks for pre-commit. To disable this behavior, pass -f / --overwrite to the install command. If you decide not to use pre-commit, pre-commit uninstall will restore your hooks to the state prior to installation. TEMPORARILY DISABLING HOOKS ¶ Not all hooks are perfect so sometimes you may need to skip execution of one or more hooks. pre-commit solves this by querying a SKIP environment variable. The SKIP environment variable is a comma separated list of hook ids. This allows you to skip a single hook instead of --no-verifying the entire commit. $ SKIP=flake8 git commit -m "foo" PRE-COMMIT DURING COMMITS ¶ Running hooks on unstaged changes can lead to both false-positives and false-negatives during committing. pre-commit only runs on the staged contents of files by temporarily saving the contents of your files at commit time and stashing the unstaged changes while running hooks. _new in 2.4.0_: pre-commit can be used to manage post-commithooks.
To use post-commit hooks with pre-commit, run: $ pre-commit install --hook-type post-commit pre-commit installed at .git/hooks/post-commit post-commit hooks fire after the commit succeeds and cannot be used to prevent the commit from happening (use pre-commit instead). Since post-commit does not operate on files, any hooks must set always_run:- repo: local
hooks:
- id: post-commit-localname: post commit
always_run: true
stages:
# ...
PRE-COMMIT DURING MERGES ¶ The biggest gripe we’ve had in the past with pre-commit hooks was during merge conflict resolution. When working on very large projects a merge often results in hundreds of committed files. I shouldn’t need to run hooks on all of these files that I didn’t even touch! This often led to running commit with --no-verify and allowed introduction of real bugs that hooks could have caught. pre-commit solves this by only running hooks on files that conflict or were manually edited during conflict resolution. This also includes files which were automatically merged by git. Git isn't perfect and this can often catch implicit conflicts (such as with removed pythonimports).
_new in 2.11.0_ pre-commit can be used to manage post-mergehooks.
To use post-merge hooks with pre-commit, run: $ pre-commit install --hook-type post-merge pre-commit installed at .git/hooks/post-merge The hook fires after a successful git merge. PRE-COMMIT DURING CLEAN MERGES ¶ _new in 1.21.0_ pre-commit can be used to manage pre-merge-commithooks.
To use pre-merge-commit hooks with pre-commit, run: $ pre-commit install --hook-type pre-merge-commit pre-commit installed at .git/hooks/pre-merge-commit The hook fires after a merge succeeds but before the merge commit iscreated.
Note that you need to be using at least git 2.24 which added support for the pre-merge-commit hook. PRE-COMMIT DURING PUSH ¶ To use pre-push hooks with pre-commit, run: $ pre-commit install --hook-type pre-push pre-commit installed at .git/hooks/pre-push During a push, pre-commit will export the following environmentvariables:
* PRE_COMMIT_FROM_REF: the remote revision that is being pushed to. * _new in 2.2.0_ prior to 2.2.0 the variable was PRE_COMMIT_SOURCE. * PRE_COMMIT_TO_REF: the local revision that is being pushed to theremote.
* _new in 2.2.0_ prior to 2.2.0 the variable was PRE_COMMIT_ORIGIN. * PRE_COMMIT_REMOTE_NAME: _new in 2.0.0_ which remote is being pushed to (for example origin) * PRE_COMMIT_REMOTE_URL: _new in 2.0.0_ the url of the remote that is being pushed to (for example git@github.com:pre-commit/pre-commit. PRE-COMMIT FOR COMMIT MESSAGES ¶ pre-commit can be used to manage commit-msghooks.
To use commit-msg hooks with pre-commit, run: $ pre-commit install --hook-type commit-msg pre-commit installed at .git/hooks/commit-msg commit-msg hooks can be configured by setting stages: . commit-msg hooks will be passed a single filename -- this file contains the current contents of the commit message which can be validated. If a hook exits nonzero, the commit will be aborted. _new in 1.16.0_: pre-commit can be used to manage prepare-commit-msghooks.
To use prepare-commit-msg hooks with pre-commit, run: $ pre-commit install --hook-type prepare-commit-msg pre-commit installed at .git/hooks/prepare-commit-msg prepare-commit-msg hooks can be used to create dynamic templates for commit messages. prepare-commit-msg hooks can be configured by setting stages: . prepare-commit-msg hooks will be passed a single filename -- this file contains any initial commit message (e.g. from git commit -m "..." or a template) and can be modified by the hook before the editor is shown. A hook may want to check for GIT_EDITOR=: as this indicates that no editor will be launched. If a hook exits nonzero, the commit will be aborted. PRE-COMMIT FOR SWITCHING BRANCHES ¶ _new in 2.2.0_: pre-commit can be used to manage post-checkouthooks.
To use post-checkout hooks with pre-commit, run: $ pre-commit install --hook-type post-checkout pre-commit installed at .git/hooks/post-checkout post-checkout hooks can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata properties. Since post-checkout doesn't operate on files, any hooks must set always_run:- repo: local
hooks:
- id: post-checkout-local name: Post checkoutalways_run: true
stages:
# ...
post-checkout hooks have three environment variables they can check to do their work: $PRE_COMMIT_FROM_REF, $PRE_COMMIT_TO_REF, and $PRE_COMMIT_CHECKOUT_TYPE. These correspond to the first, second, and third arguments (respectively) that are normally passed to a regular post-checkout hook from Git. CONFINING HOOKS TO RUN AT CERTAIN STAGES ¶ Since the default_stages top level configuration property of the .pre-commit-config.yaml file is set to all stages by default, when installing hooks using the -t/--hook-type option (see pre-commit install ), all hooks will be installed by default to run at the stage defined through that option. For instance, pre-commit install --hook-type pre-push will install by default all hooks to runat the push stage.
Hooks can however be confined to a stage by setting the stages property in your .pre-commit-config.yaml. The stages property is an array and can contain any of commit, merge-commit, push, prepare-commit-msg, commit-msg, post-checkout, post-commit, post-merge, and manual. If you do not want to have hooks installed by default on the stage passed during a pre-commit install --hook-type ..., please set the default_stages top level configuration property to the desired stages,also as an array.
_new in 1.8.0_: An additional manual stage is available for one off execution that won't run in any hook context. This special stage is useful for taking advantage of pre-commit's cross-platform / cross-language package management without running it on every commit. Hooks confined to stages: can be executed by running pre-commit run --hook-stage manual . PASSING ARGUMENTS TO HOOKS ¶ Sometimes hooks require arguments to run correctly. You can pass static arguments by specifying the args property in your .pre-commit-config.yaml as follows: - repo: https://gitlab.com/PyCQA/flake8rev: 3.8.3
hooks:
- id: flake8
args:
This will pass --max-line-length=131 to flake8. ARGUMENTS PATTERN IN HOOKS ¶ If you are writing your own custom hook, your hook should expect to receive the args value and then a list of staged files. For example, assuming a .pre-commit-config.yaml: - repo: https://github.com/path/to/your/hook/repo rev: badf00ddeadbeefhooks:
- id: my-hook-script-idargs:
When you next run pre-commit, your script will be called: path/to/script-or-system-exe --myarg1=1 --myarg1=2 dir/file1 dir/file2 file3 If the args property is empty or not defined, your script will becalled:
path/to/script-or-system-exe dir/file1 dir/file2 file3 When creating local hooks, there's no reason to put command arguments into args as there is nothing which can override them -- instead put your arguments directly in the hook entry.For example:
- repo: local
hooks:
- id: check-requirements name: check requirements fileslanguage: system
entry: python -m scripts.check_requirements --compare files: ^requirements.*.txt$ REPOSITORY LOCAL HOOKS ¶ Repository-local hooks are useful when: * The scripts are tightly coupled to the repository and it makes sense to distribute the hook scripts with the repository. * Hooks require state that is only present in a built artifact of your repository (such as your app's virtualenv for pylint). * The official repository for a linter doesn't have the pre-commitmetadata.
You can configure repository-local hooks by specifying the repo as thesentinel local.
local hooks can use any language which supports additional_dependencies or docker_image / fail / pygrep / script / system. This enables you to install things which previously would require a trivial mirror repository. A local hook must define id, name, language, entry, and files / types as specified under Creating new hooks. Here's an example configuration with a few local hooks:- repo: local
hooks:
- id: pylint
name: pylint
entry: pylint
language: system
types:
- id: check-x
name: Check X
entry: ./bin/check-x.shlanguage: script
files: \.x$
- id: scss-lintname: scss-lint
entry: scss-lint
language: ruby
language_version: 2.1.5types:
additional_dependencies:META HOOKS ¶
_new in 1.4.0_
pre-commit provides several hooks which are useful for checking the pre-commit configuration itself. These can be enabled using repo:meta.
- repo: meta
hooks:
- id: ...
The currently available meta hooks:check-hooks-apply
ensures that the configured hooks apply to at least one file in the repository. _new in 1.4.0_. check-useless-excludes ensures that exclude directives apply to _any_ file in the repository._new in 1.4.0_.
identity
a simple hook which prints all arguments passed to it, useful for debugging. _new in 1.14.0_. AUTOMATICALLY ENABLING PRE-COMMIT ON REPOSITORIES ¶_new in 1.18.0_
pre-commit init-templatedir can be used to set up a skeleton for git's init.templateDir option. This means that any newly cloned repository will automatically have the hooks set up without the need to runpre-commit install.
To configure, first set git's init.templateDir -- in this example I'm using ~/.git-template as my template directory. $ git config --global init.templateDir ~/.git-template $ pre-commit init-templatedir ~/.git-template pre-commit installed at /home/asottile/.git-template/hooks/pre-commit Now whenever you clone a pre-commit enabled repo, the hooks willalready be set up!
$ git clone -q git@github.com:asottile/pyupgrade$ cd pyupgrade
$ git commit --allow-empty -m 'Hello world!' Check docstring is first.............................(no files to check)Skipped Check Yaml...........................................(no files to check)Skipped Debug Statements (Python)............................(no files to check)Skipped...
init-templatedir uses the --allow-missing-config option from pre-commit install so repos without a config will be skipped: $ git init sample Initialized empty Git repository in /tmp/sample/.git/$ cd sample
$ git commit --allow-empty -m 'Initial commit' `.pre-commit-config.yaml` config file not found. Skipping `pre-commit`.Initial commit
To still require opt-in, but prompt the user to set up pre-commit use a template hook as follows (for example in ~/.git-template/hooks/pre-commit). #!/usr/bin/env bashif ; then
echo 'pre-commit configuration detected, but `pre-commit install` was never run' 1>&2exit 1
fi
With this, a forgotten pre-commit install produces an error on commit: $ git clone -q https://github.com/asottile/pyupgrade$ cd pyupgrade/
$ git commit -m 'foo' pre-commit configuration detected, but `pre-commit install` was never run FILTERING FILES WITH TYPES ¶ Filtering with types provides several advantages over traditional filtering with files. * no error-prone regular expressions * files can be matched by their shebang (even when extensionless) * symlinks / submodules can be easily ignored types is specified per hook as an array of tags. The tags are discovered through a set of heuristics by the identify library. identify was chosen as it is a small portable pure python library. Some of the common tags you'll find from identify:* file
* symlink
* directory - in the context of pre-commit this will be a submodule * executable - whether the file has the executable bit set * text - whether the file looks like a text file * binary - whether the file looks like a binary file * tags by extension / naming convention * tags by shebang (#!) To discover the type of any file on disk, you can use identify's cli: $ identify-cli setup.py $ identify-cli some-random-file $ identify-cli --filename-only some-random-file; echo $?1
If a file extension you use is not supported, please submit a pullrequest !
types, types_or, and files are evaluated together with AND when filtering. Tags within types are also evaluated using AND. _new in 2.9.0_: Tags within types_or are evaluated using OR.For example:
files: ^foo/
types:
will match a file foo/1.py but will not match setup.py.Another example:
files: ^foo/
types_or:
will match any of foo/bar.js / foo/bar.jsx / foo/bar.ts / foo/bar.tsxbut not baz.js.
If you want to match a file path that isn't included in a type when using an existing hook you'll need to revert back to files only matching by overriding the types setting. Here's an example of using check-json against non-json files: - id: check-json types: # override `types: ` files: \.(json|myext)$ Files can also be matched by shebang. With types: python, an exe starting with #!/usr/bin/env python3 will also be matched. As with files and exclude, you can also exclude types if necessary using exclude_types. If you'd like to use types with compatibility for older versions here is a guide to ensuring compatibility.
REGULAR EXPRESSIONS ¶ The patterns for files and exclude are python regular expressions and are matched with re.search.
As such, you can use any of the features that python regexes support. If you find that your regular expression is becoming unwieldy due to a long list of excluded / included things, you may find a verboseregular
expression useful. One can enable this with yaml's multiline literals and the (?x) regex flag.# ...
- id: my-hook
exclude: |
(?x)^(
path/to/file1.py|
path/to/file2.py|
path/to/file3.py
)$
OVERRIDING LANGUAGE VERSION ¶ Sometimes you only want to run the hooks on a specific version of the language. For each language, they default to using the system installed language (So for example if I’m running python3.7 and a hook specifies python, pre-commit will run the hook using python3.7). Sometimes you don’t want the default system installed version so you can override this on a per-hook basis by setting the language_version. - repo: https://github.com/pre-commit/mirrors-scss-lintrev: v0.54.0
hooks:
- id: scss-lint language_version: 2.1.5 This tells pre-commit to use ruby 2.1.5 to run the scss-lint hook. Valid values for specific languages are listed below: * python: Whatever system installed python interpreters you have. The value of this argument is passed as the -p to virtualenv. * _new in 1.4.3_: on windows the pep394 name will be translated into a py launcher call for portability. So continue to use names like python3 (py -3) or python3.6 (py -3.6) even on windows. * node: See nodeenv . * ruby: See ruby-build.
_new in 1.14.0_: you can now set default_language_version at the top level in your configuration to control the default versions across all hooks of a language. default_language_version: # force all unspecified python hooks to run python3python: python3
# force all unspecified ruby hooks to run ruby 2.1.5ruby: 2.1.5
BADGING YOUR REPOSITORY ¶ you can add a badge to your repository to show your contributors / users that you use pre-commit!*
Markdown:
(https://github.com/pre-commit/pre-commit)*
HTML:
*
reStructuredText:
.. image:: https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white :target: https://github.com/pre-commit/pre-commit:alt: pre-commit
*
AsciiDoc:
image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white USAGE IN CONTINUOUS INTEGRATION ¶ pre-commit can also be used as a tool for continuous integration. For instance, adding pre-commit run --all-files as a CI step will ensure everything stays in tip-top shape. To check only files which have changed, which may be faster, use something like pre-commit run --from-ref origin/HEAD --to-ref HEAD MANAGING CI CACHES ¶ pre-commit by default places its repository store in ~/.cache/pre-commit -- this can be configured in two ways: * PRE_COMMIT_HOME: if set, pre-commit will use that locationinstead.
* XDG_CACHE_HOME: if set, pre-commit will use $XDG_CACHE_HOME/pre-commit following the XDG Base DirectorySpecification
.
PRE-COMMIT.CI EXAMPLE ¶ no additional configuration is needed to run in pre-commit.ci!
pre-commit.ci also has the following benefits: * it's faster than other free CI solutions * it will autofix pull requests * it will periodically autoupdate your configurationAPPVEYOR EXAMPLE ¶
cache:
- '%USERPROFILE%\.cache\pre-commit' AZURE PIPELINES EXAMPLE ¶ note: azure pipelines uses immutable caches so the python version and .pre-commit-config.yaml hash must be included in the cache key. for a repository template, see asottile@job--pre-commit.yml.
jobs:
- job: precommit
# ...
variables:
PRE_COMMIT_HOME: $(Pipeline.Workspace)/pre-commit-cachesteps:
# ...
- script: echo "##vso$(python -VV)" - task: CacheBeta@0inputs:
key: pre-commit | .pre-commit-config.yaml | "$(PY)" path: $(PRE_COMMIT_HOME)CIRCLECI EXAMPLE ¶
like azure pipelines, circleci also uses immutable caches:steps:
- run:
command: |
cp .pre-commit-config.yaml pre-commit-cache-key.txt python --version --version >> pre-commit-cache-key.txt- restore_cache:
keys:
- v1-pc-cache-{{ checksum "pre-commit-cache-key.txt" }}# ...
- save_cache:
key: v1-pc-cache-{{ checksum "pre-commit-cache-key.txt" }}paths:
- ~/.cache/pre-commit (source: @chriselion)
GITHUB ACTIONS EXAMPLE ¶ SEE THE OFFICIAL PRE-COMMIT GITHUB ACTION like azure pipelines, github actions also uses immutable caches:- name: set PY
run: echo "PY=$(python -VV | sha256sum | cut -d' ' -f1)" >> $GITHUB_ENV - uses: actions/cache@v1with:
path: ~/.cache/pre-commit key: pre-commit|${{ env.PY }}|${{ hashFiles('.pre-commit-config.yaml') }} GITLAB CI EXAMPLE ¶ See the Gitlab caching best practicesto
fine tune the cache scope.my_job:
variables:
PRE_COMMIT_HOME: ${CI_PROJECT_DIR}/.cache/pre-commitcache:
paths:
- ${PRE_COMMIT_HOME} TRAVIS-CI EXAMPLE ¶cache:
directories:
- $HOME/.cache/pre-commitUSAGE WITH TOX ¶
tox is useful for configuring test / CI tools such as pre-commit. One feature of tox>=2 is it will clear environment variables such that tests are more reproducible. Under some conditions, pre-commit requires a few environment variables and so they must be allowed to be passed through. When cloning repos over ssh (repo: git@github.com:...), git requires the SSH_AUTH_SOCK variable and will otherwise fail: Initializing environment for git@github.com:pre-commit/pre-commit-hooks. An unexpected error has occurred: CalledProcessError: command: ('/usr/bin/git', 'fetch', 'origin', '--tags')return code: 128
expected return code: 0stdout: (none)
stderr:
git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Check the log at /home/asottile/.cache/pre-commit/pre-commit.log Add the following to your tox testenv: passenv = SSH_AUTH_SOCK Likewise, when cloning repos over http / https (repo: https://github.com:...), you might be working behind a corporate http(s) proxy server, in which case git requires the http_proxy, https_proxy and no_proxy variables to be set, or the clone may fail: passenv = http_proxy https_proxy no_proxy USING THE LATEST VERSION FOR A REPOSITORY ¶ pre-commit configuration aims to give a repeatable and fast experience and therefore intentionally doesn't provide facilities for "unpinned latest version" for hook repositories. Instead, pre-commit provides tools to make it easy to upgrade to the latest versions with pre-commit autoupdate. If you need the absolute latest version of a hook (instead of the latest tagged version), pass the --bleeding-edge parameter to autoupdate. pre-commit assumes that the value of rev is an immutable ref (such as a tag or SHA) and will cache based on that. Using a branch name (or HEAD) for the value of rev is not supported and will only represent the state of that mutable ref at the time of hook installation (and will _NOT_ update automatically).CONTRIBUTING ¶
We’re looking to grow the project and get more contributors especially to support more languages/versions. We’d also like to get the .pre-commit-hooks.yaml files added to popular linters without maintaining forks / mirrors. Feel free to submit bug reports, pull requests, and feature requests.SPONSORING ¶
If you or your company would like to support the development of pre-commit one can contribute in the following ways: * GitHub Sponsors (asottile)* Open Collective
GETTING HELP ¶
There are several ways to get help for pre-commit: * Ask a question on stackoverflow tagged pre-commit.com * Create an issue on pre-commit/pre-commit * Ask in the #pre-commit channel in asottile's twitch discordCONTRIBUTORS ¶
* website by Molly Finkle * created by Anthony Sottile * core developers: Ken Struys , ChrisKuehl
* framework contributors * core hook contributors * and users like you!Details
Copyright © 2024 ArchiveBay.com. All rights reserved. Terms of Use | Privacy Policy | DMCA | 2021 | Feedback | Advertising | RSS 2.0