-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin/LineEndingCheck: Add autocrlf warning #260
Plugin/LineEndingCheck: Add autocrlf warning #260
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved. Please consider taking the suggestions.
@apop5 I currently have a PR in edk2-pytool-extensions that synchronizes all git commands to use GitPython rather than RunCmd. tianocore/edk2-pytool-extensions#407 Once the edk2-pytool-extensions PR is in and GitPython is installed with the package, then the changes in this PR will need to be updated to something along the lines of the following: r = Repo(workspace_root)
try:
result = r.config_reader().get_value("core", "autocrlf"))
except NoOptionError as e:
pass
# Do something with this error
|
@Javagedes I'll wait and update the PR after the edk2-pytool-extensions PR completes, and a release is made and picked up. This or really is meant to be informational, so that a warning is generated. I would see problems trying to change a user's git environment. |
@apop5 you should be able to come back to this now. |
750838e
to
cb1c5f0
Compare
PR has been updated to use GitPython. |
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description 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, ... ## How This Was Tested 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). ## Integration Instructions n/a
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description 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, ... ## How This Was Tested 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). ## Integration Instructions n/a
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description 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, ... ## How This Was Tested 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). ## Integration Instructions n/a
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description 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, ... ## How This Was Tested 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). ## Integration Instructions n/a
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description 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, ... ## How This Was Tested 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). ## Integration Instructions n/a
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
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
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
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
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
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
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
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
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
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
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 (microsoft#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
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 (microsoft#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
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 (microsoft#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
Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
Description
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)
flow, or firmware?
validation improvement, ...
in build or boot behavior?
a function in a new library class in a pre-existing module, ...
outside direct code modifications (and comments)?
on an a separate Web page, ...
How This Was Tested
Testing by configuring a system with
git config --global core.autocrlf true
and running a CI build to verify message is displayed, then by configuringgit 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).
Integration Instructions
n/a