Skip to content
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

Merged
merged 1 commit into from
Feb 9, 2021
Merged

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Feb 4, 2021

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.

screen capture

@nodejs-github-bot nodejs-github-bot added meta Issues and PRs related to the general management of the project. tools Issues and PRs related to the tools directory. labels Feb 4, 2021
@aduh95 aduh95 added the wip Issues and PRs that are still a work in progress. label Feb 4, 2021
@aduh95 aduh95 marked this pull request as draft February 4, 2021 13:08
@aduh95 aduh95 marked this pull request as ready for review February 4, 2021 14:40
@aduh95 aduh95 closed this Feb 4, 2021
@aduh95 aduh95 reopened this Feb 4, 2021
@aduh95 aduh95 removed the wip Issues and PRs that are still a work in progress. label Feb 4, 2021
Copy link
Member

@richardlau richardlau left a 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)

@aduh95
Copy link
Contributor Author

aduh95 commented Feb 4, 2021

Will this result in false positives for the release PR's (e.g. see the doc changes in #36476)?

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).
IMHO it's worth it, it's easy to miss this with human eyes and we end up with PR like #37205 from time to time.

Also I wonder if it's possible to detect/pass the expected pr-url into the existing YAML linting

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 .md files of the code base, and doesn't know which lines are being add in a specific PR (nor the PR URL, but that could be set up in an environment variable).

Comment on lines +7 to +8
import process from 'node:process';
import readline from 'node:readline';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Contributor Author

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 the global 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.

Copy link
Contributor

@RaisinTen RaisinTen left a 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?

tools/lint-pr-url.mjs Outdated Show resolved Hide resolved
@aduh95 aduh95 requested a review from RaisinTen February 8, 2021 10:34
const changeDelimiter = /^@@ -\d+,\d+ \+(\d+),\d+ @@/;
const prUrlDefinition = /^\+\s+pr-url: (.+)$/;

const validatePrUrl = (url) => url == null || url === expectedPrUrl;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const validatePrUrl = (url) => url == null || url === expectedPrUrl;
const validatePrUrl = (url) => url === expectedPrUrl;


let currentFile;
let currentLine;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
} else if (!validatePrUrl(line.match(prUrlDefinition)?.[1])) {
} else if (currentPrUrl = line.match(prUrlDefinition)?.[1] &&
validatePrUrl(currentPrUrl)) {

@RaisinTen
Copy link
Contributor

@aduh95 currently, validatePrUrl returns true for null, so, no warning is thrown for lines like:

+ 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 }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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)?

Copy link
Contributor Author

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.

@aduh95
Copy link
Contributor Author

aduh95 commented Feb 8, 2021

@aduh95 currently, validatePrUrl returns true for null, so, no warning is thrown for lines like:

+ pr-url: 

Added some suggestions to fix that.

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 lint-md.

@RaisinTen
Copy link
Contributor

Can we disable lint-md from doing such checks?
I was considering adding this change here because lint-md only runs on PRs
that are ready for review, so pr-urls wouldn't be linted completely by this tool:

lint-md:
if: github.event.pull_request.draft == false

@aduh95
Copy link
Contributor Author

aduh95 commented Feb 8, 2021

Can we disable lint-md from doing such checks?
I was considering adding this change here because lint-md only runs on PRs
that are ready for review, so pr-urls wouldn't be linted completely by this tool:

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 lint-md more permissive, I've added this rule because there were quite a few mistakes that was spotted only when the rule was added; removing it would almost certainly mean we'll start seeing a few of those mistakes hoping here and there.

@nodejs-github-bot
Copy link
Collaborator

@RaisinTen RaisinTen added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 8, 2021
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

PR-URL: nodejs#37221
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Darshan Sen <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@aduh95
Copy link
Contributor Author

aduh95 commented Feb 9, 2021

Landed in 33d3a2e

@aduh95 aduh95 merged commit 33d3a2e into nodejs:master Feb 9, 2021
@aduh95 aduh95 deleted the pr-url-lint branch February 9, 2021 10:46
danielleadams pushed a commit that referenced this pull request Feb 16, 2021
PR-URL: #37221
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Darshan Sen <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
This was referenced Feb 16, 2021
targos pushed a commit that referenced this pull request May 1, 2021
PR-URL: #37221
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Darshan Sen <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@danielleadams danielleadams mentioned this pull request May 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. meta Issues and PRs related to the general management of the project. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants