This check requires authors to initialize empty or zero builtin types
using the literal syntax (e.g., `{}` instead of `dict()`).
Authors may ignore this requirement for certain builtins using the
`--ignore` option.
Authors may also forbid calling `dict()` with keyword arguments
(`dict(a=1, b=2)`) using the `--no-allow-dict-kwargs` flag.
* add no commit code and config
* add the code
* remove version tweak
* fix logic, remove newline
* add Tests and cleanup testing issues
* remove extraneous modules
* cleanup some pep8 and flake issues
* reorder imports
* more fixes for syntax checking
* code cleanup based off asottile comments
* Use Contractions Properly, alphabatize new hook.
* Adding support for branches with a slash in them.
In the event that there exists no configuration for AWS credentials and
they are not exported in to the current environment, a flag may be
passed to allow exiting the hook successfully.
Resolves#174
Signed-off-by: Mike Fiedler <miketheman@gmail.com>
Turns out there is an additional environment variable AWS_CONFIG_FILE,
which gets evaluated for finding configuration files as well. This
commit adds support for it.
The previous approach for finding AWS credentials was pretty naive and
only covered contents of a single file (~/.aws/credentials by
default).
The AWS CLI documentation states various other ways to configure
credentials which weren't covered:
https://docs.aws.amazon.com/cli/latest/topic/config-vars.html#credentials
Even that aren't all ways, a look into the code shows:
https://github.com/boto/botocore/blob/develop/botocore/credentials.py
This commit changes the behavior so the hook will behave in a way
that if the AWS CLI is able to obtain credentials from local files,
the hook will find them as well.
The changes in detail are:
- detect AWS session tokens and handle them like secret keys.
- always search credentials in the default AWS CLI file locations
( ~/.aws/config, ~/.aws/credentials, /etc/boto.cfg and ~/.boto)
- detect AWS credentials configured via environment variables in
AWS_SECRET_ACCESS_KEY, AWS_SECURITY_TOKEN and AWS_SESSION_TOKEN
- check additional configuration files configured via environment
variables (AWS_CREDENTIAL_FILE, AWS_SHARED_CREDENTIALS_FILE and
BOTO_CONFIG)
- print out the first four characters of each secret found in files to
be checked in, to make it easier to figure out, what the secrets
were, which were going to be checked in
- improve error handling for parsing ini-files
- improve tests
There is a major functional change introduced by this commit:
Locations the AWS CLI gets credentials from are always searched and
there is no way to disable them. --credentials-file is still there to
specify one or more additional files to search credentials in. It's
the purpose of this hook to find and check files for found
credentials, so it should work in any case. As this commit also
improves error handling for not-existing or malformed configuration
files, it should be no big deal.
Receiving credentials via the EC2 and ECS meta data services is not
covered intentionally, to not further increase the amount of changes
in this commit and as it's probably an edge case anyway to have this
hook running in such an environment.
This new hook allows to standardize one's JSON files (sorted key/4
spaces indent).
By default it just fails if any file is not complying with the standard,
but you can also pass the arg `--autofix` and the hook will
pretty-format the file itself.
Good in use combined with the `check-json` hook.
Markdown uses two or more trailing spaces on a line to indicate a forced
line break `<br/>` - these will be preserved for files with a markdown
extension (default = `.md` or `.markdown`).
Add `--markdown-linebreak-ext=X,Y` to add extensions (`*` matches any),
and `--no-markdown-linebreak-ext` to disable this feature.
If you want to set specific extension `foo` only (and not md/markdown),
use `--no-markdown-linebreak-ext --markdown-linebreak-ext=foo`
Tries to prevent --markdown-linebreak-ext from eating filenames as if they were
extensions by rejecting any with '.' or '/' (or even Windows-style '\' or ':')
Update README.md to include information on these arguments as well as
arguments added to other hooks
Add extensive tests using pytest.mark.parametrize
test that `txt` file is not considered as 'txt' extension
test that `.txt` file is not considered as 'txt' extension
The latter is the (correct) behavior of os.path.splitext(), and an example
of why it is better to use the libraries than to mangle strings yourself.
Do a straight test of detecting a real merge conflict as generated by git.
Test artificial conflict detection while pending merge without a real conflict.
Test artificial non-conflict non-detection in a resolved merge conflict.
Rename test_does_not_care... function to reflect what we want to care about.
Rename is_in_merge_conflict to is_in_merge since that is what it checks.
Several markup formats, such as Markdown or Re(Structured)Text
can format titles as text with '=' characters as double underlining,
like this:
```
My Page Title
=============
Lorem ipsum...
```
Rather that considering any line starting with seven '=' as a conflict marker,
require a space (or line-ending newline) after the equals.
This could still create a false positive for a seven character title,
like "Problem", but the markup formats generally allow extra '=' characters,
so by formatting the text like this:
```
Problem
========
Not...
```
these pre-commit warnings can be avoided.
Also updates the tests to add newlines for more realistic conflict files
(while a file might not end with a newline, conflict markers will).
Prevent false negative on test_does_not_care_when_not_in_a_conflict()
by making sure that README.md contains a line identical to a conflict string
(exactly seven '=' followed by a newline).
Ben Webber