| /openbmc/openbmc-build-scripts/ |
| H A D | .gitignore | fb9948a3 Tue Jun 21 11:10:24 CDT 2022 Ed Tanous <edtanous@google.com> Enforce commit message style
Throughout the project, it is a manual human process to enforce the idea
of commit message formatting, and leads to more conflict than would
ideally be required for something that's relatively algorithmic, and
able to be enforced by CI. Jenkins is able to give faster response
times to users, thus ensuring that committers are more likely to be able
to resolve their commit message issues in a timely manner.
This commit adds the gitlint[1] application to our builds, and
integrates its checks with CI in the format-code.sh script. Gitlint
appears to be a relatively active project with a number of releases,
relatively up to date commits on its github, and by the documentation as
well as this authors testing, appears to do exactly what the project
needs in terms of checks.
gitlint has a number of configuration options[2], of which the defaults
appear to be ok for OpenBMCs style requirements. This commit checks in a
.gitlint file that was generated via 'gitlint generate-config' to use as
a starting point.
To avoid impacting the entire project at this time, this commit checks
for the existence of a .openbmc-enforce-gitlint file in the root of the
directory, and uses that to gate its scanning. At some point in the
future, once we've determined this meets our needs, this check will be
removed so that we can enforce this project-wide.
This commit makes use of the gitlint plugin system to support one
important feature that OpenBMC requires for block line length. The
custom line length rule allows:
1. Block comments to exceed the line length limit
2. Signed-Off-By sections to exceed the line length limit
3. Tabbed in sections to exceed the line length limit
Presumably this same mechanism could be used to handle openbmc/openbmc
commits, to allow meta-<name> to precede the title and go over the
allowed limit, but for the moment, format-code.sh does not apply to
openbmc/openbmc, so this would be for a future change to repotest
When these fails, it attempts to give the user a message that conveys
these allowals to let them fix their commit message quickly.
Tested:
Created a commit with a title that was too long, as well as added a
.openbmc-enforce-gitlint file in bmcweb. Ran openbmc-build-scripts and observed.
'''
-: UC1 Line exceeds max length (101>72).
It's possible you intended to use one of the following exceptions:
1. Put logs or bash lines in a quoted section with triple quotes (''') before and after the section
2. Put a long link at the bottom in a footnote. example: [1] https://my_long_link.com
Line that was too long:
: "VERY LONG LOG LINE THAT TAKES WAY TOO MUCH SPACE AND GOES OVER 72 CHARACTERS, which is a problem"
'''
[1] https://jorisroovers.com/gitlint/
[2] https://jorisroovers.com/gitlint/configuration/
[3] https://jorisroovers.com/gitlint/user_defined_rules/
[4] https://github.com/jorisroovers/gitlint/issues/255#issuecomment-1063494186
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42a22bfeca223fd5bc8f35ed937aa5f60713f2a
|
| /openbmc/openbmc-build-scripts/config/ |
| H A D | .gitlint | fb9948a3 Tue Jun 21 11:10:24 CDT 2022 Ed Tanous <edtanous@google.com> Enforce commit message style
Throughout the project, it is a manual human process to enforce the idea
of commit message formatting, and leads to more conflict than would
ideally be required for something that's relatively algorithmic, and
able to be enforced by CI. Jenkins is able to give faster response
times to users, thus ensuring that committers are more likely to be able
to resolve their commit message issues in a timely manner.
This commit adds the gitlint[1] application to our builds, and
integrates its checks with CI in the format-code.sh script. Gitlint
appears to be a relatively active project with a number of releases,
relatively up to date commits on its github, and by the documentation as
well as this authors testing, appears to do exactly what the project
needs in terms of checks.
gitlint has a number of configuration options[2], of which the defaults
appear to be ok for OpenBMCs style requirements. This commit checks in a
.gitlint file that was generated via 'gitlint generate-config' to use as
a starting point.
To avoid impacting the entire project at this time, this commit checks
for the existence of a .openbmc-enforce-gitlint file in the root of the
directory, and uses that to gate its scanning. At some point in the
future, once we've determined this meets our needs, this check will be
removed so that we can enforce this project-wide.
This commit makes use of the gitlint plugin system to support one
important feature that OpenBMC requires for block line length. The
custom line length rule allows:
1. Block comments to exceed the line length limit
2. Signed-Off-By sections to exceed the line length limit
3. Tabbed in sections to exceed the line length limit
Presumably this same mechanism could be used to handle openbmc/openbmc
commits, to allow meta-<name> to precede the title and go over the
allowed limit, but for the moment, format-code.sh does not apply to
openbmc/openbmc, so this would be for a future change to repotest
When these fails, it attempts to give the user a message that conveys
these allowals to let them fix their commit message quickly.
Tested:
Created a commit with a title that was too long, as well as added a
.openbmc-enforce-gitlint file in bmcweb. Ran openbmc-build-scripts and observed.
'''
-: UC1 Line exceeds max length (101>72).
It's possible you intended to use one of the following exceptions:
1. Put logs or bash lines in a quoted section with triple quotes (''') before and after the section
2. Put a long link at the bottom in a footnote. example: [1] https://my_long_link.com
Line that was too long:
: "VERY LONG LOG LINE THAT TAKES WAY TOO MUCH SPACE AND GOES OVER 72 CHARACTERS, which is a problem"
'''
[1] https://jorisroovers.com/gitlint/
[2] https://jorisroovers.com/gitlint/configuration/
[3] https://jorisroovers.com/gitlint/user_defined_rules/
[4] https://github.com/jorisroovers/gitlint/issues/255#issuecomment-1063494186
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42a22bfeca223fd5bc8f35ed937aa5f60713f2a
|
| /openbmc/openbmc-build-scripts/config/gitlint/ |
| H A D | block_comment.py | fb9948a3 Tue Jun 21 11:10:24 CDT 2022 Ed Tanous <edtanous@google.com> Enforce commit message style
Throughout the project, it is a manual human process to enforce the idea
of commit message formatting, and leads to more conflict than would
ideally be required for something that's relatively algorithmic, and
able to be enforced by CI. Jenkins is able to give faster response
times to users, thus ensuring that committers are more likely to be able
to resolve their commit message issues in a timely manner.
This commit adds the gitlint[1] application to our builds, and
integrates its checks with CI in the format-code.sh script. Gitlint
appears to be a relatively active project with a number of releases,
relatively up to date commits on its github, and by the documentation as
well as this authors testing, appears to do exactly what the project
needs in terms of checks.
gitlint has a number of configuration options[2], of which the defaults
appear to be ok for OpenBMCs style requirements. This commit checks in a
.gitlint file that was generated via 'gitlint generate-config' to use as
a starting point.
To avoid impacting the entire project at this time, this commit checks
for the existence of a .openbmc-enforce-gitlint file in the root of the
directory, and uses that to gate its scanning. At some point in the
future, once we've determined this meets our needs, this check will be
removed so that we can enforce this project-wide.
This commit makes use of the gitlint plugin system to support one
important feature that OpenBMC requires for block line length. The
custom line length rule allows:
1. Block comments to exceed the line length limit
2. Signed-Off-By sections to exceed the line length limit
3. Tabbed in sections to exceed the line length limit
Presumably this same mechanism could be used to handle openbmc/openbmc
commits, to allow meta-<name> to precede the title and go over the
allowed limit, but for the moment, format-code.sh does not apply to
openbmc/openbmc, so this would be for a future change to repotest
When these fails, it attempts to give the user a message that conveys
these allowals to let them fix their commit message quickly.
Tested:
Created a commit with a title that was too long, as well as added a
.openbmc-enforce-gitlint file in bmcweb. Ran openbmc-build-scripts and observed.
'''
-: UC1 Line exceeds max length (101>72).
It's possible you intended to use one of the following exceptions:
1. Put logs or bash lines in a quoted section with triple quotes (''') before and after the section
2. Put a long link at the bottom in a footnote. example: [1] https://my_long_link.com
Line that was too long:
: "VERY LONG LOG LINE THAT TAKES WAY TOO MUCH SPACE AND GOES OVER 72 CHARACTERS, which is a problem"
'''
[1] https://jorisroovers.com/gitlint/
[2] https://jorisroovers.com/gitlint/configuration/
[3] https://jorisroovers.com/gitlint/user_defined_rules/
[4] https://github.com/jorisroovers/gitlint/issues/255#issuecomment-1063494186
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42a22bfeca223fd5bc8f35ed937aa5f60713f2a
|
| /openbmc/openbmc-build-scripts/scripts/ |
| H A D | format-code.sh | fb9948a3 Tue Jun 21 11:10:24 CDT 2022 Ed Tanous <edtanous@google.com> Enforce commit message style
Throughout the project, it is a manual human process to enforce the idea
of commit message formatting, and leads to more conflict than would
ideally be required for something that's relatively algorithmic, and
able to be enforced by CI. Jenkins is able to give faster response
times to users, thus ensuring that committers are more likely to be able
to resolve their commit message issues in a timely manner.
This commit adds the gitlint[1] application to our builds, and
integrates its checks with CI in the format-code.sh script. Gitlint
appears to be a relatively active project with a number of releases,
relatively up to date commits on its github, and by the documentation as
well as this authors testing, appears to do exactly what the project
needs in terms of checks.
gitlint has a number of configuration options[2], of which the defaults
appear to be ok for OpenBMCs style requirements. This commit checks in a
.gitlint file that was generated via 'gitlint generate-config' to use as
a starting point.
To avoid impacting the entire project at this time, this commit checks
for the existence of a .openbmc-enforce-gitlint file in the root of the
directory, and uses that to gate its scanning. At some point in the
future, once we've determined this meets our needs, this check will be
removed so that we can enforce this project-wide.
This commit makes use of the gitlint plugin system to support one
important feature that OpenBMC requires for block line length. The
custom line length rule allows:
1. Block comments to exceed the line length limit
2. Signed-Off-By sections to exceed the line length limit
3. Tabbed in sections to exceed the line length limit
Presumably this same mechanism could be used to handle openbmc/openbmc
commits, to allow meta-<name> to precede the title and go over the
allowed limit, but for the moment, format-code.sh does not apply to
openbmc/openbmc, so this would be for a future change to repotest
When these fails, it attempts to give the user a message that conveys
these allowals to let them fix their commit message quickly.
Tested:
Created a commit with a title that was too long, as well as added a
.openbmc-enforce-gitlint file in bmcweb. Ran openbmc-build-scripts and observed.
'''
-: UC1 Line exceeds max length (101>72).
It's possible you intended to use one of the following exceptions:
1. Put logs or bash lines in a quoted section with triple quotes (''') before and after the section
2. Put a long link at the bottom in a footnote. example: [1] https://my_long_link.com
Line that was too long:
: "VERY LONG LOG LINE THAT TAKES WAY TOO MUCH SPACE AND GOES OVER 72 CHARACTERS, which is a problem"
'''
[1] https://jorisroovers.com/gitlint/
[2] https://jorisroovers.com/gitlint/configuration/
[3] https://jorisroovers.com/gitlint/user_defined_rules/
[4] https://github.com/jorisroovers/gitlint/issues/255#issuecomment-1063494186
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42a22bfeca223fd5bc8f35ed937aa5f60713f2a
|
| H A D | build-unit-test-docker | fb9948a3 Tue Jun 21 11:10:24 CDT 2022 Ed Tanous <edtanous@google.com> Enforce commit message style
Throughout the project, it is a manual human process to enforce the idea
of commit message formatting, and leads to more conflict than would
ideally be required for something that's relatively algorithmic, and
able to be enforced by CI. Jenkins is able to give faster response
times to users, thus ensuring that committers are more likely to be able
to resolve their commit message issues in a timely manner.
This commit adds the gitlint[1] application to our builds, and
integrates its checks with CI in the format-code.sh script. Gitlint
appears to be a relatively active project with a number of releases,
relatively up to date commits on its github, and by the documentation as
well as this authors testing, appears to do exactly what the project
needs in terms of checks.
gitlint has a number of configuration options[2], of which the defaults
appear to be ok for OpenBMCs style requirements. This commit checks in a
.gitlint file that was generated via 'gitlint generate-config' to use as
a starting point.
To avoid impacting the entire project at this time, this commit checks
for the existence of a .openbmc-enforce-gitlint file in the root of the
directory, and uses that to gate its scanning. At some point in the
future, once we've determined this meets our needs, this check will be
removed so that we can enforce this project-wide.
This commit makes use of the gitlint plugin system to support one
important feature that OpenBMC requires for block line length. The
custom line length rule allows:
1. Block comments to exceed the line length limit
2. Signed-Off-By sections to exceed the line length limit
3. Tabbed in sections to exceed the line length limit
Presumably this same mechanism could be used to handle openbmc/openbmc
commits, to allow meta-<name> to precede the title and go over the
allowed limit, but for the moment, format-code.sh does not apply to
openbmc/openbmc, so this would be for a future change to repotest
When these fails, it attempts to give the user a message that conveys
these allowals to let them fix their commit message quickly.
Tested:
Created a commit with a title that was too long, as well as added a
.openbmc-enforce-gitlint file in bmcweb. Ran openbmc-build-scripts and observed.
'''
-: UC1 Line exceeds max length (101>72).
It's possible you intended to use one of the following exceptions:
1. Put logs or bash lines in a quoted section with triple quotes (''') before and after the section
2. Put a long link at the bottom in a footnote. example: [1] https://my_long_link.com
Line that was too long:
: "VERY LONG LOG LINE THAT TAKES WAY TOO MUCH SPACE AND GOES OVER 72 CHARACTERS, which is a problem"
'''
[1] https://jorisroovers.com/gitlint/
[2] https://jorisroovers.com/gitlint/configuration/
[3] https://jorisroovers.com/gitlint/user_defined_rules/
[4] https://github.com/jorisroovers/gitlint/issues/255#issuecomment-1063494186
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42a22bfeca223fd5bc8f35ed937aa5f60713f2a
|