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: replace deprecated CI job #21938

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion COLLABORATOR_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -210,7 +210,7 @@ is the standard CI run we do to check Pull Requests. It triggers
`node-test-commit`, which runs the `build-ci` and `test-ci` targets on all
supported platforms.

* [`node-test-pull-request-lite`](https://ci.nodejs.org/job/node-test-pull-request-lite/)
* [`node-test-pull-request-lite-pipeline`](https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/)
only runs the linter job, as well as the tests on LinuxONE, which is very fast.
This is useful for changes that only affect comments or documentation.

Expand Down
2 changes: 1 addition & 1 deletion doc/onboarding.md
Original file line number Diff line number Diff line change
Expand Up @@ -213,7 +213,7 @@ needs to be pointed out separately during the onboarding.
* Optionally, include your personal pronouns.
* Label your pull request with the `doc` and `notable-change` labels.
* Run CI on the PR. Because the PR does not affect any code, use the
`node-test-pull-request-lite` CI task. Alternatively, use the usual
`node-test-pull-request-lite-pipeline` CI task. Alternatively, use the usual
`node-test-pull-request` CI task and cancel it after the linter and one other
subtask have passed.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe one for @nodejs/build to comment on, but my own experience with Jenkins is that cancelling jobs can sometimes leave workspaces in a bad state (usually manifesting in git checkout errors on subsequent runs) depending on where the job was at at the time it was cancelled so I'm not generally in favour of encouraging the cancellation of jobs.

Copy link
Contributor

Choose a reason for hiding this comment

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

From my personal experience, a lot of git checkout errors / infra failures in general with ci.nodejs.org can be linked back to issues with the machine itself, not usually due to cancelling jobs early. Also, you could say there's a benefit from new collaborators practicing how to launch node-test-pull-request jobs. I'd rather folks let the build go all the way through and finish, but I don't think they're "breaking our infra" by cancelling it early.

Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer that cancelling jobs is not encouraged at all, I've seen a lot of failures because of it. It may not be the most frequent issue but it happens.

At least two cases are know: 1) Abort during a git operation will leave behind a lock file that will make all following jobs on that machine fail; 2) Visual Studio will not stop running immediately after the job is aborted, locking some files and making git clean fail for some time/jobs (happens easily when there are queued jobs). Note that Jenkins does not offer us any reliable way of running anything between jobs, so fixing this is not straightforward.

(To be clear, I'm also not blocking this PR, but would be in favor of deleting the sentence starting at "Alternatively".)

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 will make a new PR after landing to draw more attention to this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PR: #21977

* After one or two approvals, land the PR (PRs of this type do not need to wait
Expand Down