In fact, this can be done even at the stage of the release build, in order to avoid unnecessary bot commits(per each PR) and line conflicts, writing the entire block of changes at once.

I would think more how to implement this one, because I wouldn't like to have a lot of bot commits 😅

That would be really very helpful! 👍 I already thought about this, the only thing is not always clear how to automatically classify PR (Added / Changed) 🤔

In fact, this can be done even at the stage of the release build, in order to avoid unnecessary bot commits(per each PR) and line conflicts, writing the entire block of changes at once.

There are two options to do that:

1. Follows Conventional Commits rules and uses prefixes: feat and fix. To ensure that contributors follow these rules we can add the commitlint;
2. Uses labels like feature and changes.

I like more the first option.

Closes #329

<!-- Please make sure to review and check all of these items: -->

✔ Checklist:

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] This PR has been added to CHANGELOG.md (at the top of the list);

<!-- NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. -->

https://tekin.co.uk/2020/10/better-git-diff-output-for-ruby-python-elixir-and-more

*.rs diff=rust
*.md diff=markdown

Are these indents necessary?

But in general, it is not necessary that in the future the structure of the output does not change much with the appearance of the output "on the fly" 🙂

@DDtKey Maybe you would like to implement on-the-fly output? 😉

It seems to me that it was about interactive mode. When we see the progress of checking files on the fly (many CLI utilities do just that)

You are absolutely right. This is just the first iteration. We can add the progress of checking files on the fly later.

Perhaps the dotenv-linter works very quickly and even with a large number of files it is not necessary, but in this case, it generally does not make much sense, except for displaying the files that have been checked(which is also important) 🤔

Right now dotenv-linter does not output anything if it did not find problems in the .env files. In such situation, it is not obvious to the user whether dotenv-linter has checked all the files or not. So, this PR fixes that case.

https://tekin.co.uk/2020/10/better-git-diff-output-for-ruby-python-elixir-and-more

@Anthuang Thank you! I'm going to merge this PR after v2.2.1 release.

@Nikhil0487 Thank you! I'm going to merge this PR after v2.2.1 release.

@mgrachev @DDtKey

I have analyzed (including going through colored repo) and I couldn't figure out how to test colored/--no-color output. All the output with/without -no-color flag gives output without any color.

Any clues/hints would help me to come up with something.

Nothing comes to mind right now. Let's delete this test because it's useless.

@Anthuang Please fix conflicts.

When in recursive mode: do not follow symbolic links within target directories. See #326.

• Add check in crate::get_file_paths to only get subdirectories if they are not symlinks.

• Add test with a cyclic symlink.

• Add symlink creation function for unix and windows to use in test.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests. -->

<!-- Please make sure to review and check all of these items: -->

✔ Checklist:

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated (for bug fixes / features).

<!-- NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. -->

Create a single file and a symbolic link to its containing dir:

$ mkdir -p /tmp/project
$ echo 'ohno' > /tmp/project/.env
$ ln -s /tmp/project/ /tmp/project/back_to_root
$ tree -a /tmp/project
/tmp/project
├── back_to_root -> /tmp/project/
└── .env

Run linter with recursive search:

$ cargo run -- -r /tmp/project/
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/dotenv-linter -r /tmp/project/`
../../../../tmp/project/.env:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/back_to_root/.env:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/back_to_root/back_to_root/.env:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
[snipped]

Found 41 problems

It follows the link and rechecks the same file again and again.

Possible solutions:

1. Don't follow links
2. Keep track of already visited dirs in canonicalized form

@ametalon Thank you for your help! 🚀

🙏 If it’s not difficult for you, please support the project - click on the star on GitHub ⭐️

First stab at #323 This implementation hard-excludes files and there is no way to run checks on them. Even running the linter with these files listed explicitly will still skip them.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests. -->

<!-- Please make sure to review and check all of these items: -->

✔ Checklist:

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated (for bug fixes / features).

<!-- NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. -->

direnv uses .envrc files which are bash scripts, and dotenv-linter is attempting to parse those. When I ran dotenv-linter, I got the following as errors:

.envrc:2 KeyWithoutValue: The source_up key should be with a value or have an equal sign
.envrc:4 KeyWithoutValue: The use kerl --auto key should be with a value or have an equal sign
.envrc:5 KeyWithoutValue: The use kiex --auto key should be with a value or have an equal sign
.envrc:6 KeyWithoutValue: The use nvm --auto key should be with a value or have an equal sign
.envrc:7 KeyWithoutValue: The use chruby --auto key should be with a value or have an equal sign
.envrc:10 KeyWithoutValue: The dotenv key should be with a value or have an equal sign

All of these are correct, because they are functions in either the direnv standard library or in an extension that I have on my computer.

As direnv-based .envrc files are not merely .env files but full bash scripts, it is probably less than ideal that .envrc files are included in the default scanning pattern, and I would suggest that a warning be printed if scanning .envrc files manually.

The auto-fix for shell functions &c with direnv scripts breaks things badly:

--- .envrc	2020-10-15 11:48:53.000000000 -0400
+++ .envrc.backup	2020-07-16 22:11:45.000000000 -0400
@@ -1,13 +1,13 @@
 # shellcheck disable=SC2148
-source_up=
+source_up
 
-use chruby --auto=
-use kerl --auto=
-use kiex --auto=
-use nvm --auto=
+use kerl --auto
+use kiex --auto
+use nvm --auto
+use chruby --auto
 
 # use dotenv for compatibility with Docker and Docker Compose
-dotenv=
+dotenv

@Aashu23 Thank you! 👍

🙏 If it’s not difficult for you, please support the project - click on the star on GitHub ⭐️

@mgrachev Fixed the issue Updated tests accordingly

Fixes #325

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);

Create 3 files in one dir:

$ mkdir -p /tmp/project
$ for f in a b c; do echo "ohno" > /tmp/project/.env.$f; done
$ tree -a /tmp/project
/tmp/project
├── .env.a
├── .env.b
└── .env.c

Listing whole dir twice leads to each file being checked twice:

$ cargo run -- /tmp/project/ /tmp/project/
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/dotenv-linter /tmp/project/ /tmp/project/`
../../../../tmp/project/.env.a:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.b:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.c:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.a:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.b:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.c:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign

Found 6 problems

Listing file .env.a and whole dir works as expected:

$ cargo run -- /tmp/project/ /tmp/project/.env.a
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/dotenv-linter /tmp/project/ /tmp/project/.env.a`
../../../../tmp/project/.env.a:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.b:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.c:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign

Found 3 problems

Hovewer, listing file .env.b and whole dir leads to the file being checked twice:

$ cargo run -- /tmp/project/ /tmp/project/.env.b
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/dotenv-linter /tmp/project/ /tmp/project/.env.b`
../../../../tmp/project/.env.b:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.a:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.b:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign
../../../../tmp/project/.env.c:1 KeyWithoutValue: The ohno key should be with a value or have an equal sign

Found 4 problems

I guess the issue is here https://github.com/dotenv-linter/dotenv-linter/blob/281a2030aa66bd3d3dcbbabb1636659548e96a98/src/lib.rs#L101-L103 Sorted file names extended with file names from dirs and then consecutive duplicates removed.

In case with file .env.a:

# file names
/tmp/project/.env.a
# file names from dirs
/tmp/project/.env.a <- removed by deduplication
/tmp/project/.env.b
/tmp/project/.env.c

In case with file .env.b:

# file names
/tmp/project/.env.b
# file names from dirs
/tmp/project/.env.a
/tmp/project/.env.b <- isn't removed because there are no consecutive duplicates here
/tmp/project/.env.c

Switching order of sorting and extending should fix the issue. Yay, 100 line long babbling for 2 line change in code!

- Add default exclude list [#324](https://github.com/dotenv-linter/dotenv-linter/pull/324) ([@ametalon](https://github.com/ametalon))

Okay, let it be 🙂

Currently `dotenv-linter` doesn't check `.envrc` files because [direnv](https://direnv.net) uses them as bash scripts.

Why this file is needed? You don't use it in the test case.

Why this file is needed? You don't use it in the test case.

- Fix linter rechecking files if they were listed more than once [#327](https://github.com/dotenv-linter/dotenv-linter/pull/327) ([@Aashu23](https://github.com/Aashu23))

You can't create files with the same name in the same directory.

You can't create files with the same name in the same directory.

Update hadolint to v1.18.2 Compare v1.18.0...v1.18.2

This PR is auto generated by depup workflow.

- Fix linter rechecking files if they were listed more than once [#327](https://github.com/dotenv-linter/dotenv-linter/pull/327) ([@aashu23](https://github.com/Aashu23))

@ametalon Thank you! I like more the first option.

@dotenv-linter/core What do you think?

@ametalon Thank you for your help! We are planning to fix this bug in the next release.

Sure, just wanted to make sure that you ok with the approach I took. Readme doesn't mention exclusion option at all and redirects to the docs for more info. Should I copy paragraph from the docs or leave readme as is? I'm failing to see how I can add stuff to the docs, could you give me directions?

All documentation lives here: https://github.com/dotenv-linter/dotenv-linter.github.io

Please add information about these changes to this page https://dotenv-linter.github.io/#/usage (at the bottom of the page)

const IGNORE_LIST: &[&str] = &[".envrc"]; // https://direnv.net

I like the name IGNORE_LIST better. What do you think about it? Also, it would be great if you added a comment why we ignore this file name.

@vk26 Thank you for your contribution! 🙂

Add action-yamllint to .github/workflows

Add action-yamllint to lint yaml files.

Link: https://github.com/reviewdog/action-yamllint

@vk26 Thank you for your contribution! 🚀

Add action-yamllint to .github/workflows/

Add action-yamllint to lint yaml files.

Link: https://github.com/reviewdog/action-yamllint

@dem23step Good catch! Thanks a lot! 🙏

@vk26 Thank you for your contribution! ❤️

Add action-yamllint to .github/workflows/

Add action-yamllint to lint yaml files.

Link: https://github.com/reviewdog/action-yamllint

@vk26 Thank you for your contribution! 💪

Add action-yamllint to .github/workflows/

Add action-yamllint to lint yaml files.

Link: https://github.com/reviewdog/action-yamllint

@vk26 Thank you for your contribution! 🚀

Add action-yamllint to .github/workflows/

Add action-yamllint to lint yaml files.

Link: https://github.com/reviewdog/action-yamllint