* Lint the whole code base with JSCPD if VALIDATE_ALL_CODEBASE is true
* Use VALIDATE_JSCPD_ALL_CODEBASE
Co-authored-by: Lukas Gravley <admiralawkbar@github.com>
* Add support for google-java-format
* adding tests and array
* fix comma
* Update linter.sh
* get it in order
* fix hava version
Co-authored-by: Admiral Awkbar <admiralawkbar@github.com>
In the README.md file the example value of `GITHUB_CUSTOM_API_URL` for usage on GHES ends in a `api/v3/` this is incorrect, instead `api/v3` needs to be used. Also it states that the defautl value is `api.github.com`, the true default value is `https://api.github.com`, this again is confusing whether or not the `https` needs to be included or not (it does need to be included)
Co-authored-by: Lukas Gravley <admiralawkbar@github.com>
* Improve wording of LINTER_RULES_PATH docs (#1634).
* Add a template config file for ShellCheck (#1633).
Instruct ShellCheck to search SCRIPTDIR, the directory that the script
being linted is in, for other scripts that are sourced. Otherwise, the
commonly-used source command results in linter error SC1091. See
https://github.com/koalaman/shellcheck/wiki/SC1091 for more details.
* fix line ending
Co-authored-by: Lukas Gravley <admiralawkbar@github.com>
* Ignore files marked with @generated marker
`@generated` marker is used by certain tools to understand that the
file is generated, so it should be treated differently than a file
written by a human:
* these files do not need to be reformatted,
* diffs in these files are less important,
* and linters should not be invoked on these files.
This PR proposes builtin support for `@generated` marker (and
`@not-generated` marker to mark file as not generated when it
contains `@generated` marker, like `README.md`).
I have not found a standard for a generated file marker, but:
* Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated)
* Phabricator tool which was spawned from Facebook internal tool
[also understands `@generated` marker](https://git.io/JnVHa)
* Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP)
Super-linter supports regex includes and excludes, but they are
harder to maintain (each repository needs to be configured) than
patching the tools which generate the files.
My personal story is that I maintain rust-protobuf crate, which
started emitting `@generated` markers [six years ago](https://git.io/JnV5h)
after a request of a Phabricator user.
Test Plan:
Create a test file `test.sh`:
```
echo $a
```
Run:
```
docker run -e RUN_LOCAL=true -v $HOME/tmp/g:/tmp/lint super-linter-test
```
Result is:
```
In /tmp/lint/test.sh line 1:
echo $a
^-- SC2148: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
^-- SC2154: a is referenced but not assigned.
^-- SC2086: Double quote to prevent globbing and word splitting.
...
2021-06-22 23:46:16 [ERROR] ERRORS FOUND in BASH:[1]
```
Now add `@generated` to the file and run again:
```
2021-06-22 23:47:13 [NOTICE] All file(s) linted successfully with no errors detected
```
Additionally, add `@not-generated` in addition to `@generated`, and
linter error pops up again.
* cleanup
* remove space
* fix non utf return
* fix non utf return
Co-authored-by: Lukas Gravley <admiralawkbar@github.com>
* adding rules file
* fix naming
* cleanup
* make smart
* fixing the make
* adding template
* white space
* not sure how i got windows
* found the space
* adding new one...
* adding automation
* linter
* pull apart for faster builds
* maybe
* update automation
* fix that
* prime is smart
* fixed it
* quotes
* fix build image
* inpec
* typo
* forgot backslash
* fixed hairbrain logic
* this should help cleanup
* i hate r
* order
* maybe fix r
* maybe fix r
* update readme
* remove spaces
* update
* adding it
* fix typo
* fix tests
* adding back jsonlint
* adding back jsonlint
* fix spacing
* found the typo
* add tests
* adding rules for json
* add to local
* adding cert
* update readme
* typo
* make exec
* spaces
* adding better way
* adding example
* make shell happy
* fix space
* adding notes
* bad var
* duh
* Generate a code coverage report
* make linters happy
* adding action and badge
* no report for me
* Upload the test report
* adding folders
* spaces not tabs
* makefiles love tabs
* spacing is important
* rawr
* Fix makefile
* Add diagnostic info
* Set UID and GID
* Make info
* Add docker images in diagnostic info
* Move info before testing the local action
* Add missing -C to git diff-tree
* Reset ownership
* Add missing quotes
* Sudo
* Attempt to fix ARM test
* Attempt to fix go test
Co-authored-by: Admiral Awkbar <admiralawkbar@github.com>
* adding fun
* fix whitespace
* adding tests
* adding the array
* bug in file name
* fix tap
* makes no sense
* adding the hammer
* adding some extra protbuf
* Support custom rules with markdownlint
* Add MARKDOWN_CUSTOM_RULE_GLOBS to README.md
* Fix shellcheck issues and use bash array for globs
* Fix shfmt issues
Co-authored-by: Gabriel Diaz <gabo.fdc@gmail.com>
* Ignore files that are ignored by Git
* Add missing continue statement
* Fix linting errors
* Fix linting errors
* like it
* like it
* Add the IGNORE_GITIGNORED_FILES variable
* Fix setting the Ansible directory when running tests
* Fix var export
* Update linter.sh
Co-authored-by: Admiral Awkbar <admiralawkbar@github.com>
* Improved ANSIBLE_DIRECTORY validation to support the repository root
Fixes#1110, which prevents linting playbooks at the root of the repository from being supported.
* Trim whitespace
* Remove undesired extra validation condition
Addressing review feedback from @ ferrarimarco
* Avoid mutating ANSIBLE_DIRECTORY beyond the extent that was already in place
Co-authored-by: Lukas Gravley <admiralawkbar@github.com>
Added a "Using your own rules files" section to the
README under the "Template rules" section.
This section may help developers new to super-linter
avoid running into issues #864 and #685.
I think it probably makes more sense for the examples in this README to follow YAML syntax, assuming that people will be running super-linter as a GitHub Action. There's a separate doc covering the process for running the linter locally, in which case, of course, environment variables would be set with an equals sign. It's not a big deal, but I thought I would make the suggestion.
