Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
.pytool/Plugin/LineEndingCheck: Fix scanning and other changes
Makes the following changes: 1. Recursively discovers files in packages instead of just checking the top-level package directory. The pattern should recursively find files relative to the package which accomplished with `**` in this change. 2. Differentiates between binary and text files, skipping line ending checks in binary files. 3. Verifies a path discovered is a file. Directories may rarely contain a dot in the name appearing in the path result list. 4. For files with issues, print the relative file path to the workspace. This is less than verbose than absolute, unique enough to find the file, and recognized for shortcut clicking in IDEs like VS Code. 5. For files with issues, print the relative file path to the file in POSIX format (with forward slashes). This makes copy/ paste easy to tools like unixtodos and is equally recognized as a valid file path in IDEs like VS Code on Windows. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> .pytool/Plugin/LineEndingCheck: Add git ignore support Adds support to ignore git ignored files and files under submodules since those are either addressed in their respective repo's CI or from an external project. Some optimizations are also made to improve performance. As the comment in the code states, these changes call the system git command until GitPython is more widely used in the edk2 tool modules. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Plugin/LineEndingCheck: Add autocrlf warning (#260) LineEndingCheck's ReadMe.md recommends that autocrlf=false, but developers may not have configured their system with this setting. This change generates a warning message when it determines that the autocrlf does not match the recommended setting. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [ ] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... Testing by configuring a system with `git config --global core.autocrlf true` and running a CI build to verify message is displayed, then by configuring `git config --global core.autocrlf false` and running a CI build to verify warning message is not displayed. Tested when no core.autocrlf is is set (deleting from config file). n/a
- Loading branch information