-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
tools: add GitHub Action linter for pr-url #37221
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.
Will this result in false positives for the release PR's (e.g. see the doc changes in #36476)?
Also I wonder if it's possible to detect/pass the expected pr-url into the existing YAML linting done in https://github.com/nodejs/remark-preset-lint-node/blob/0b2a13018de6ad9bcd234e4420bba03ae9f42c29/remark-lint-nodejs-yaml-comments.js#L134-L139 (see https://github.com/nodejs/node/runs/1825250022#step:5:11 for an example of a detected malformed pr-url)
Yes, it would print out warnings, but the workflow would still end with a green ticks – it only outputs warnings and not errors (so it wouldn't interfere with ncu or the commit queue).
I remember trying to do that when I added the YAML linting a while back, but couldn't find a way: the linter parses all |
import process from 'node:process'; | ||
import readline from 'node:readline'; |
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.
import process from 'node:process'; | |
import readline from 'node:readline'; | |
import readline from 'readline'; |
nit: since process
is a part of the global
object
question: why are we prepending 'node:'
to the imported module names?
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.
nit: since
process
is a part of theglobal
object
I try to not rely on Node.js-only globals when writing ES modules to ease a potential port to the browser. I really don't feel strongly about that, and am willing to remove the import if anyone disagrees.
question: why are we prepending
'node:'
to the imported module names?
Every time we try to introduce a new module in core comes the question of how breaking it would be for the ecosystem (is there a module that use the same name out there). It's been discussed several time to add a prefix to core modules, and with ESM we had to come up with a URL scheme to be spec compliant. TSC has decided that it will be ported to the CJS resolver as well (see #36098), so why not use it.
Again, I don't feel strongly about that either, if the consensus is not to use the prefix, that'd be fine with me.
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.
The currentLine
gets incremented over parts of the diff log where
line
is deleted (prepended with -
s) whereas we want currentLine
to remain the same while traversing deletions. Hence, the warning will
point to incorrect line numbers though line
holds the correct value.
How should we fix this?
const changeDelimiter = /^@@ -\d+,\d+ \+(\d+),\d+ @@/; | ||
const prUrlDefinition = /^\+\s+pr-url: (.+)$/; | ||
|
||
const validatePrUrl = (url) => url == null || url === expectedPrUrl; |
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.
const validatePrUrl = (url) => url == null || url === expectedPrUrl; | |
const validatePrUrl = (url) => url === expectedPrUrl; |
|
||
let currentFile; | ||
let currentLine; | ||
|
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.
let currentPrUrl; | |
console.log(`Parsing changes in ${currentFile}.`); | ||
} else if (changeDelimiter.test(line)) { | ||
currentLine = Number(line.match(changeDelimiter)[1]); | ||
} else if (!validatePrUrl(line.match(prUrlDefinition)?.[1])) { |
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.
} else if (!validatePrUrl(line.match(prUrlDefinition)?.[1])) { | |
} else if (currentPrUrl = line.match(prUrlDefinition)?.[1] && | |
validatePrUrl(currentPrUrl)) { |
@aduh95 currently, + pr-url: Added some suggestions to fix that. |
@@ -98,3 +98,12 @@ jobs: | |||
- uses: mszostok/[email protected] | |||
with: | |||
checks: "files,duppatterns" | |||
lint-pr-url: | |||
if: ${{ github.event.pull_request }} |
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.
if: ${{ github.event.pull_request }} | |
if: github.event.pull_request.draft == false |
Isn't this supposed to be the check here (based on the above jobs)?
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.
I meant to check only pull request (it wouldn't work on push, because it needs a PR URL), and I believe it's fine to have it running on draft PRs because it doesn't produce errors.
That doesn't seem necessary, that kind of checks are already made by the linter, it would produce a warning on top of the error from |
Can we disable node/.github/workflows/linters.yml Lines 42 to 43 in d75f3e9
|
If you open a PR to re-enable linter GH actions for draft PR, I'd gladly approve it (I'm with with on that, I think it makes opening draft PR useless). I don't think it's a good idea to make |
PR-URL: nodejs#37221 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Darshan Sen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Landed in 33d3a2e |
PR-URL: #37221 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Darshan Sen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #37221 Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Darshan Sen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
The PR URL is unknown when someone starts working on a change, they may
be tempted to use a placeholder with a "fake" PR URL value to make the
linter pass on their local machine. This commit adds warnings when a
pr-url doesn't correspond to the actual PR URL to help reviewers spot
those "fake" URLs before landing.