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

doc: update CI requirements for landing pull requests #37308

Merged
merged 1 commit into from
Feb 26, 2021

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Feb 10, 2021

The current text contain repetitions and inconsistencies. Also, I think there are some cases where Jenkins CI doesn't have any added value (linter changes, adding GH actions scripts, doc generation tool updates, etc.) but it's still required today.

This PR suggests to list folders where the full Jenkins CI is actually needed. For changes outside of those critical folders, I think GH actions results would report all the relevant mistakes already.

/cc @nodejs/tsc

If this change is accepted, I can work on a PR to reflect this change on node-core-utils.

@aduh95 aduh95 added meta Issues and PRs related to the general management of the project. tsc-agenda Issues and PRs to discuss during the meetings of the TSC. labels Feb 10, 2021
@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Feb 10, 2021
@richardlau
Copy link
Member

This PR suggests to list folders where the full Jenkins CI is actually needed. For changes outside of those critical folders, I think GH actions results would report all the relevant mistakes already.

Unfortunately I think this will end up being very complicated. We absolutely need to run a full Jenkins CI on anything that touches a build file (e.g. any of the .gyp files including the ones in the root directory and tools/v8_gypfiles). Also other directories under tools such as gyp, icu, inspector-protocol, snapshot, etc. All of those contain either source or a tool that could break on any of the platforms that the Jenkins CI covers that are not available from GitHub.

Comment on lines 220 to 223
- `deps/`
- `lib/`
- `src/`
- `test/`
Copy link
Contributor Author

@aduh95 aduh95 Feb 10, 2021

Choose a reason for hiding this comment

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

@richardlau would this list cover everything?

Suggested change
- `deps/`
- `lib/`
- `src/`
- `test/`
* `deps/`
* `lib/`
* `src/`
* `test/`

Copy link
Member

Choose a reason for hiding this comment

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

No, it would miss things like (not exhaustive) tools/build-addons.js, tools/genv8constants.py, tools/js2c.py, tools/test.py, tools/v8_gypfiles

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

platforms are only kept for seven days.

#### Useful CI jobs
A green GitHub Actions CI result is required. A passing
Copy link
Member

Choose a reason for hiding this comment

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

Yellow is also OK.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, wait, GitHub Actions CI. Yeah, so maybe it is just green.

We've never required GitHub Actions CI be green before. This would be a big change in the process. I'm not opposed, necessarily, but I want to highlight this here so it doesn't escape notice.

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.

Since this is getting approvals, I'm going to make my concerns with this explicit. Our CI requirements are already confusing, especially to newcomers to the project (who might just expect the GitHub actions to be sufficient), and this change introduces more complexity (which I think will be unavoidable with the current mix of stuff that lives in tools/). We do not require collaborators use node-core-utils, which means our rules should aim to be simple to follow.

If we do make changes it may be simpler to state when GitHub actions only is sufficient (e.g. in addition to documentation-only changes, add changes to .github, etc.).

Even "(except it only changes comments)" is not something I'm entirely comfortable with as it's perfectly possible to break code when changing comments, e.g. mismatched /* and */ in C/C++ which could always be inside #if def's so wouldn't necessary be caught in the actions CI.

@aduh95
Copy link
Contributor Author

aduh95 commented Feb 10, 2021

Even "(except it only changes comments)" is not something I'm entirely comfortable with

I put it there because it was already in the rules – I didn't know about it before working on this PR, and I suspect most collaborators haven't heard of it either.

Our CI requirements are already confusing
this change introduces more complexity
our rules should aim to be simple to follow.

Hum OK, my aim was actually to simplify the requirements by allowing more PRs to land without going to the Jenkins full run (which is sometimes flaky and causes confusion to new contributors). But I get your point, we should try to improve the collaborator experience as well.
I was thinking we could make the boot assign the needs-ci label to the PRs that introduce changes to the listed files. Also, we can add another rule: "When in doubt, spawn a Jenkins CI" (which is already implicitly the case).

If we do make changes it may be simpler to state when GitHub actions only is sufficient (e.g. in addition to documentation-only changes, add changes to .github, etc.).

That's something I've considered, I'm not sure it'd be ideal in the long run though: I think most files that are being added to the repo are either not related with the build process, either inside one of the listed folders; that would make the list go out-of-date quicker than the current one. Anyway, if that's the way we decide to make it, the exception list would look something like that:

* `*.md`,
* `.eslintrc.js`,
* `benchmark/`,
* `doc/`,
* `tools/actions/`,
* `tools/doc/`,
* `tools/eslint-rules/`,
* `tools/node_modules/`,
* `tools/node-lint-md-cli-rollup/`,
* `tools/lint-*.*`,
* `tools/release.sh`,
* `tools/update-authors.js`
* `tools/osx-*.sh`

@richardlau richardlau dismissed their stale review February 11, 2021 11:03

Clearing my block based on most recent updates in 50a2af3.

@aduh95 aduh95 added the blocked PRs that are blocked by other issues or PRs. label Feb 11, 2021
@aduh95
Copy link
Contributor Author

aduh95 commented Feb 11, 2021

Adding the blocked label to avoid this to land too soon – I'd like to get more reviews, and to be sure this has consensus we can maybe wait for the next TSC meeting.

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

To the best of my knowledge, this all makes sense, is accurate and IMO doesn't complicate things.

@aduh95 aduh95 added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. and removed blocked PRs that are blocked by other issues or PRs. tsc-agenda Issues and PRs to discuss during the meetings of the TSC. labels Feb 26, 2021
PR-URL: nodejs#37308
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@aduh95
Copy link
Contributor Author

aduh95 commented Feb 26, 2021

Landed in fbda84e

@aduh95 aduh95 merged commit fbda84e into nodejs:master Feb 26, 2021
@aduh95 aduh95 deleted the ci-requirements-pr branch February 26, 2021 10:19
targos pushed a commit to nodejs/node-core-utils that referenced this pull request Feb 26, 2021
targos pushed a commit that referenced this pull request Feb 28, 2021
PR-URL: #37308
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
targos pushed a commit that referenced this pull request May 1, 2021
PR-URL: #37308
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@danielleadams danielleadams mentioned this pull request May 3, 2021
johnfrench3 pushed a commit to johnfrench3/core-utils-node that referenced this pull request Nov 2, 2022
renawolford6 added a commit to renawolford6/node-dev-build-core-utils that referenced this pull request Nov 10, 2022
Developerarif2 pushed a commit to Developerarif2/node-core-utils that referenced this pull request Jan 27, 2023
gerkai added a commit to gerkai/node-core-utils-project-build that referenced this pull request Jan 27, 2023
shovon58 pushed a commit to shovon58/node-core-utils that referenced this pull request Jun 9, 2023
patrickm68 added a commit to patrickm68/NodeJS-core-utils that referenced this pull request Sep 14, 2023
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. doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.