nodejs / core-validate-commit Goto Github PK

Which subsystem is ./configure.py in? Should there be a root subsystem?

It would be cool to check whether there is some text after the metadata block, because that sometimes happens unintentionally when squashing commits together, e.g. in my nodejs/node@c5545f2.

(I may find the time to look into this myself, but just in case I don’t, I want to have mentioned it)

The project used to use coveralls until it was moved into the nodejs organization upon which it stopped working.

It seems the approved coverage tool in the organization is Codecov (used by nodejs/citgm and nodejs/node-core-utils. Should we enable that for this repo?

https://travis-ci.com/nodejs/node/jobs/165397175#L478-L491

*** Commit message for 793eb528fc is:
src: use std::vector for setting up process.execPath

Use `std::vector` as an RAII-style alternative to allocating
and deleting raw memory storage.

+npx -q core-validate-commit --no-validate-metadata 793eb528fc8a0e5b9e4d63e268080c8e90978a2b
  ✖  793eb528fc8a0e5b9e4d63e268080c8e90978a2b
     ✔  0:0      skipping fixes-url                        fixes-url
     ✔  0:0      blank line after title                    line-after-title
     ✔  0:0      line-lengths are valid                    line-length
     ✔  0:0      valid subsystems                          subsystem
     ✖  0:13     Add a space after subsystem(s).           title-format
     ⚠  0:50     Title should be <= 50 columns.            title-length

Add a hook to call core-validate-commit when you check in

tl;dr: I'd like to open a PR to replace the node_js section in the .travis.yml with an imported https://github.com/nodejs/ci-config-travis/blob/master/lts/gte-8.yml

Background: Package Maintenance WG has built a repository of shared Travis CI imports. The imports will be automatically updated as new Node.js versions get released.

Judging by what's inside the current .travis.yml here, and the missing engines in the package.json, I suspect that the lts upgrade policy is the right fit (it adds new versions as soon as they are released, never removes LTS versions, removes non-LTS versions when they reach EOL).

Is that OK?

Thanks for this tool -- it seems very useful!

However, when I tried to run it on this commit, a TypeError was thrown.

I used:

$ npm install -g core-validate-commit
$ core-validate-commit ead820d1429308595e84c5af2440839317f9a1c0

The following error was thrown:

/usr/local/lib/node_modules/core-validate-commit/lib/rules/title-length.js:19
    if (context.title.length > len) {
                     ^

TypeError: Cannot read property 'length' of undefined
    at Rule.validate [as _validate] (/usr/local/lib/node_modules/core-validate-commit/lib/rules/title-length.js:19:22)
    at Rule.validate (/usr/local/lib/node_modules/core-validate-commit/lib/rule.js:28:10)
    at ValidateCommit.lint (/usr/local/lib/node_modules/core-validate-commit/lib/index.js:51:14)
    at load (/usr/local/lib/node_modules/core-validate-commit/bin/cmd.js:131:9)
    at exec (/usr/local/lib/node_modules/core-validate-commit/bin/cmd.js:51:5)
    at ChildProcess.exithandler (child_process.js:197:7)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)

This PR was merged with a non-imperative verb starting the commit message: benchmark: added new benchmarks for blob.

From what the docs says, it should be a invalid message.

The CI did raised an error about the length (that I fix) but didn't raise an error about this verb and it was merged.

While working on issue #69 I started to come across places where it was a little difficult to test if just a particular flag was called. I think it might help if some of the logic that is in cmd.js is broken out into its own file, so it would be easier to test if a particular flag was specified, and not necessarily test what that flag actually does. That could be done in its own separate test, where it would be easier to mock certain functions.

@richardlau @Trott thoughts?

I can send a PR so we can talk about it also

Sort of related to #58, but this command would list the available subsystems to choose from.

When i was creating a Node core PR, i got a validation error because i used a subsystem that wasn't defined, then i had to go into the code of this repo to find the available ones.

Having the ability to list those values from the core-validate-commit tool would have been nice.

I not sure how the command might look though. maybe something like

core-validate-commit --list subsystem or something

I'm more than happy to work on getting a PR ready for discussion

Refs: https://github.com/joyeecheung/node-core-utils/pull/72#pullrequestreview-74269096

If the tool generating the metadata is not sure about something, it can put a ? before the metadata, and let core-validate-commit complain. For example, if someone LGTM via comments, the tool can generate the reviewer as:

?Reviewed-By: someone <[email protected]>

When i was adding in the tests for the --list-subsystem flag, i noticed that there were no tests for the other command line flags.

Now that there is a test for list-subsystems(which has affected the code coverage), there should probably be tests for the other commands

Instead of creating separate issues for each command, this issue is to track the addition of those other tests.

• usage
• version
• validate-metadata
• tap
• list
• list-subsystems

I'm happy to continue working on adding these items :)

Per the collaborator guide:

Commits are reverted with git revert , or git revert .. for multiple commits. Commit metadata and the reason for the revert should be appended. Commit message rules about line length and subsystem can be ignored. A Pull Request should be raised and approved like any other change.

Should we alleviate the 72 characters rule for lines with long URLs?

Example: nodejs/node#17107

✖ 2:7 Fixes must be a GitHub URL. fixes-url

I get this when I try to link to https://github.com/nodejs/node-gyp/issues. Fix in the works.

I know we are missing "inspector", not sure what else though.

I believe we should add esm or loader and bootstrap as valid subsystem. Besides that we also have a lot going on with trace events, so that should probably added as well.

It would be nice to continuously keep tests passing. We will need to figure out a way to get CI working with this. I don't think we are at the point where we can enable travis, are we?

Before I forget -- for Jenkins to pick up tap properly we need to write to file.

In nodejs/node#42934, I was trying to revert nodejs/node#27371, so git revert automatically created this commit title for me:

Revert "bootstrap: delay the instantiation of maps in per-context scripts"

which has 74 characters. Since it exceeds our maximum limit of 72 characters, the commit message linter failed on CI - https://github.com/nodejs/node/runs/6248053065?check_suite_focus=true#step:6:15

Run echo "::add-matcher::.github/workflows/commit-lint-problem-matcher.json"
npm WARN exec The following package was not found and will be installed: core-validate-commit
# b04fe688d5859f707cf1a5e0206967268118bf7a
ok 1 co-authored-by-is-trailer: no Co-authored-by metadata
ok 2 fixes-url: skipping fixes-url # SKIP
ok 3 line-after-title: blank line after title
ok 4 line-length: line-lengths are valid
ok 5 subsystem: valid subsystems [bootstrap]
ok 6 title-format: Title is formatted correctly.
Error: not ok 7 title-length: Title must be <= 72 columns.
  ---
    {
      found: 74,
      compare: '<=',
      wanted: 72,
      at: {
        line: 0,
        column: 72,
        body: 'Revert "bootstrap: delay the instantiation of maps in per-context scripts"'
      }
    }
  ...

0..7
# tests 7
# pass  5
# fail  1
# Please review the commit message guidelines:
# https://github.com/nodejs/node/blob/HEAD/doc/contributing/pull-requests.md#commit-message-guidelines

As a workaround, I had to change the commit title to

bootstrap: stop delaying instantiation of maps in per-context scripts

which has 69 characters (< 72) but it isn't satisfying anymore. :/

Instead of failing, IMO the linter should accept standard revert commit titles regardless of the size.