Use the newer macros?

These are in the same order as listed above so your key should be above Shelley’s.

tap2junit source is https://github.com/nodejs/tap2junit

@iandrc I think the copyfile behaviour is mostly in libuv. If I remember correctly the macOS implementation changed at some point (https://github.com/libuv/libuv/pull/2233) in libuv (also see follow up https://github.com/libuv/libuv/pull/2578).

At the very least it sounds like we should have a test for this (either in Node.js and/or libuv).

FWIW there was concern raised before ESM was unflagged in Node.js 12 and it was discussed in the Release WG and TSC (both meetings were recorded) prior to going ahead. It was acknowledged by people involved with the modules team that there was risk that the change could result in an observable change in behaviour.

Install OpenJDK Java via the yum repository for IBM i.

WIP at the moment. Have run against test-iinthecloud-ibmi72-ppc64_be-2 but not run any builds yet. Had to pass -Djava.net.preferIPv4Stack=true to the Jenkins agent start command to get the agent to start up (otherwise the agent would fail to start with java.net.SocketException: Protocol driver not attached.). cc @ThePrez

The current permissions for the libuv CI jobs looks like this:

(I'm not aware of the history behind why there are individuals in the access table)

I would like to propose giving libuv collaborators (libuv*Collaborators) permission to configure the jobs. This would be in a similar manner to what we have documented for working groups (https://github.com/nodejs/build/blob/master/GOVERNANCE.md#jenkins-job-configuration-access) with libuv the group with the "ability to run/cancel jobs" (as currently the case) and libuv*Collaborators "ability to modify jobs".

Related is an effort to trim down libuv*Collaborators to active collaborators (https://github.com/libuv/libuv/pull/2682#issuecomment-589758303) which would reduce the number of people in the group who would be given the additional permission.

cc @nodejs/libuv

It doesn't sound like there's much enthusiasm for this so I'll close.

I vaguely remembered https://github.com/nodejs/node/pull/29592 (not specifics, just the general gist of it) and CTRL+F searched through https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md for console and then util. Probably not the most efficient way.

If those two PRs (or one of them) were the fix then it's highly unlikely we'd backport to 10.x.

If this is going to be unused then this should just be

require('../common');

Glancing through the changelog for 12, I'd guess https://github.com/nodejs/node/pull/25046 (explicitly marked (dont-land-on-v10.x) and/or https://github.com/nodejs/node/pull/23162 (markedsemver-major`, see also discussion in https://github.com/nodejs/node/pull/29592) could be at play.

To set some expectations, Node.js 10.x is in maintenance now, which means there are no scheduled further updates planned (it will continue to get critical security fixes up until it's End-of-Life in April 2021). If there are small, low risk changes the Release WG may allow them to land on the v10.x-staging branch.

I think it would be desirable to have an environment variable to specify a fallback location of the node sources or the location of the tarball. Especially being able to avoid network access would be nice.

node-gyp will convert any environment variable whose name begins with npm_config_ to the equivalent option. So you should already be able to set e.g. npm_config_nodedir or npm_config_tarball.

https://github.com/nodejs/node-gyp/blob/aaf33c30296ddb71c12e2b587a5ec5add3f8ace0/lib/node-gyp.js#L136-L154

cc @nodejs/platform-ibmi

FWIW I made a small fix to the lite-ci pipeline: nodejs/node#34531 (comment)

I think we should just remove lite-ci from Jenkins. Since we started adding more Actions it doesn't bring any value to us and it ends up being one more Jenkins job to maintain (I'm not even sure if it is working, the last run took only five minutes).

I have no objections. I think the only reasons people run lite-ci is they're either not up to date with policy (just Actions are adequate for doc-only PRs) or are trying to silence git node land ... (which itself hasn't caught up with policy for doc-only PRs when it checks for CI runs).

(five minutes is plausible, the lite job only runs the linters and build/test on LinuxONE which can complete that quickly if there are no code changes and a populated ccache.)

Should this also be in sync with people that have release keys https://github.com/nodejs/node/#release-keys

@ruyadorno Friendly reminder to PR your GPG key into the Node.js readme and docker-node as per https://github.com/nodejs/Release/blob/master/GOVERNANCE.md#adding-new-releasers

I think what may be happening in the CI is that all() is short circuiting and is_valid doesn't run on all of the files returned by the glob(s).

  sys.exit(0 if all(list(map(is_valid, files))) else 1)

may fix that, or there may be a more Pythonic way of ensuring we run the function against every item returned by the iterator(s) to get all the warnings printed. cc @nodejs/python

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

@ronag The new test this introduced appears to have failed in today's daily on AIX, FreeBSD and IBM i: https://ci.nodejs.org/job/node-daily-master/2022/

e.g. https://ci.nodejs.org/job/node-test-commit-freebsd/34779/nodes=freebsd11-x64/testReport/(root)/test/parallel_test_http_parser_timeout_reset/

Mismatched noop function calls. Expected exactly 3, actual 6.
    at Proxy.mustCall (/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/common/index.js:331:10)
    at Server.<anonymous> (/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/parallel/test-http-parser-timeout-reset.js:37:42)
    at Object.onceWrapper (events.js:420:28)
    at Server.emit (events.js:314:20)
    at emitListeningNT (net.js:1322:10)
    at processTicksAndRejections (internal/process/task_queues.js:79:21)

@dmabupt Please raise a pull request in this repository with the appropriate changes to https://github.com/nodejs/node/blob/master/doc/api/fs.md.

FWIW I made a small fix to the lite-ci pipeline: https://github.com/nodejs/node/pull/34531#issuecomment-667929763

re. citgm, I can't remember the last time I used that feature, or if it still works. (Or, for that matter, whether it triggered the job to test CITGM itself or the job to test lookup.json changes.) If we do want that feature I've a soft preference to adopting the add a label to start CI mechanism that was recently added for core.

@nodejs/build can you check this?

I've added a + prefix to the git ref, which should allow for non-fast forward references: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec

Rerun CI-Lite: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/4195/

Also related to node-core-utils: could we read the list of members from @nodejs/collaborators and @nodejs/tsc instead of relying on parsing?

I think the reason it parses the readme is to get email addresses for the commit metadata (the added Reviewed-by:).

Additionally, make it easier to understand in raw markdown by removing the GitHub link. In the GitHub interface, that link will be provided automatically.

I don’t think that’s true?

Have you considered making the annotations another progress indicator rather than another option?

Fixes: https://github.com/nodejs/build/issues/2393

Replace several duplicated tasks for installing Java from builds provided by AdoptOpenJDK with a set of common tasks.

Remove hardcoded Java release specific paths.

Thanks to @sxa for pointing me at the AdoptOpenJDK API which these changes use to fetch the latest release for Java version being installed.

<details> <summary>An example use of the API</summary>

https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ga?architecture=ppc64le&image_type=jre&jvm_impl=openj9&os=linux&project=jdk&heap_size=normal&page_size=1&sort_method=DEFAULT&sort_order=DESC&vendor=adoptopenjdk

[
    {
        "binaries": [
            {
                "architecture": "ppc64le",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jre",
                "jvm_impl": "openj9",
                "os": "linux",
                "package": {
                    "checksum": "b1c91e757195b87d51027ea97fece00ac1adb9837b055e5f039dd45511fb3c0a",
                    "checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u265-b01_openj9-0.21.0/OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz.sha256.txt",
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u265-b01_openj9-0.21.0/OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz",
                    "name": "OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz",
                    "size": 48506506
                },
                "project": "jdk",
                "scm_ref": "openj9-0.21.0",
                "updated_at": "2020-07-29T15:39:20Z"
            }
        ],
        "download_count": 466,
        "id": "MDc6UmVsZWFzZTI5MDY1MjIz.h/htfG2PeOnElg==",
        "release_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u265-b01_openj9-0.21.0",
        "release_name": "jdk8u265-b01_openj9-0.21.0",
        "release_type": "ga",
        "timestamp": "2020-07-29T10:03:22Z",
        "updated_at": "2020-07-29T10:03:22Z",
        "vendor": "adoptopenjdk",
        "version_data": {
            "build": 1,
            "major": 8,
            "minor": 0,
            "openjdk_version": "1.8.0_265-b01",
            "security": 265,
            "semver": "8.0.265+1"
        }
    }
]

</details>

I've run the updated scripts against test-ibm-aix71-ppc64_be-1, and test-osuosl-centos7-ppc64_le-1 to update the version of Java used on those. I'll wait for some feedback/reviews before updating the rest.

Updated:

• [x] release-ibm-aix71-ppc64_be-1
• [x] release-osuosl-centos7-ppc64_le-1
• [x] test-ibm-aix71-ppc64_be-1
• [x] test-ibm-aix71-ppc64_be-2
• [x] test-osuosl-aix72-ppc64_be-2
• [x] test-osuosl-centos7-ppc64_le-1
• [x] test-osuosl-centos7-ppc64_le-2

Originally posted by @richardlau in https://github.com/nodejs/build/issues/2387#issuecomment-662366511:

... update the version of Java 8 that we're using -- we're currently using https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u192-b12 which is from October 2018 (https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u262-b10 is the current Java 8). https://github.com/nodejs/build/blob/9cf3680add6ee833cff9bdf855d5c9ab70c1532a/ansible/roles/java-base/tasks/main.yml#L124-L129

• [ ] Update ansible scripts
• [ ] Run ansible to update
  • [ ] test-ibm-aix71-ppc64_be-1
  • [ ] test-ibm-aix71-ppc64_be-2
  • [ ] test-osuosl-centos7-ppc64_le-1
  • [ ] test-osuosl-centos7-ppc64_le-2

We're currently using binaries from https://github.com/AdoptOpenJDK/openjdk8-releases/ on most of the IBM platforms in the CI (other platforms are using package managers). We've hardcoded URLs into ansible/roles/java-base/tasks/main.yml and these link directly to a specific version of Java 8.

i.e.

• AIX https://github.com/nodejs/build/blob/9cf3680add6ee833cff9bdf855d5c9ab70c1532a/ansible/roles/java-base/tasks/main.yml#L124-L129

• Linux on Power https://github.com/nodejs/build/blob/9cf3680add6ee833cff9bdf855d5c9ab70c1532a/ansible/roles/java-base/tasks/main.yml#L35-L39)

• LinuxONE https://github.com/nodejs/build/blob/9cf3680add6ee833cff9bdf855d5c9ab70c1532a/ansible/roles/java-base/tasks/main.yml#L64-L68

The versions being used on AIX and Linux on Power are circa 2018 (the LinuxONE version is from January of this year so is reasonably up to date):

• May 2018: https://github.com/AdoptOpenJDK/openjdk8-releases/releases/tag/jdk8u172-b11
• October 2018: https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u192-b12

At this time the most recent version of Java 8 is either:

• https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u262-b10
• https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u262-b10_openj9-0.21.0 (if we want to switch to J9 like we have done for LinuxONE)

Updated the remaining hosts.

The nodejs/node-chakracore team has been deleted and no longer exists. Remove from the captured normal security matrix.

Refs: https://github.com/nodejs/admin/issues/526

I've removed the team from the security matrix for both release and test Jenkins. This PR updates the image used in the guide for security releases.

Before: (i.e. the existing static-assets/jenkins-authorization-normal.png but with Jenkins now showing that nodejs*chakracore was not found).

After:

Unfortunately it looks like Jenkins is currently broken (https://github.com/nodejs/build/issues/2362#issuecomment-667176124 cc @nodejs/build-infra) -- would be interesting to see how the CI linter results tally.

There's still some sort of weirdness going on. The lint-cpp job from the linter workflow is failing for this PR:

Run make lint-cpp
  make lint-cpp
  shell: /bin/bash -e {0}
  env:
    PYTHON_VERSION: 3.8
    NODE_VERSION: 10.x
    pythonLocation: /opt/hostedtoolcache/Python/3.8.5/x64
Running C++ linter...
using statements aren't sorted in 'test/addons/repl-domain-abort/binding.cc'.
	Line 28: Actual: v8::Local, Expected: v8::Isolate
	Line 29: Actual: v8::Isolate, Expected: v8::Local
Makefile:1337: recipe for target 'tools/.cpplintstamp' failed
make: *** [tools/.cpplintstamp] Error 1
##[error]Process completed with exit code 2.

but I'm seeing more failures when I run against a fresh clone locally:

-bash-4.2$ ls
-bash-4.2$ git clone https://github.com/addaleax/node -b fix-cpp-import-check-weirdness --depth=1
Cloning into 'node'...
remote: Enumerating objects: 32499, done.
remote: Counting objects: 100% (32499/32499), done.
remote: Compressing objects: 100% (27110/27110), done.
remote: Total 32499 (delta 7011), reused 14193 (delta 4235), pack-reused 0
Receiving objects: 100% (32499/32499), 74.99 MiB | 2.49 MiB/s, done.
Resolving deltas: 100% (7011/7011), done.
Checking out files: 100% (32854/32854), done.
-bash-4.2$ cd node/
-bash-4.2$ git rev-parse HEAD
22c467d5ae4c505a2e61b6bcba644a72a8513ecc
-bash-4.2$ make lint-cpp
Running C++ linter...
using statements aren't sorted in 'test/addons/repl-domain-abort/binding.cc'.
        Line 28: Actual: v8::Local, Expected: v8::Isolate
        Line 29: Actual: v8::Isolate, Expected: v8::Local
File "test/addons/async-hooks-promise/binding.cc" does not use "NewStringType"
File "test/addons/dlopen-ping-pong/binding.cc" does not use "NewStringType"
using statements aren't sorted in 'test/addons/dlopen-ping-pong/binding.cc'.
        Line 19: Actual: v8::Object, Expected: v8::NewStringType
        Line 20: Actual: v8::NewStringType, Expected: v8::Object
File "test/addons/non-node-context/binding.cc" does not use "Function"
File "test/addons/non-node-context/binding.cc" does not use "FunctionTemplate"
File "test/addons/non-node-context/binding.cc" does not use "NewStringType"
File "test/addons/uv-handle-leak/binding.cc" does not use "Object"
using statements aren't sorted in 'test/cctest/test_util.cc'.
        Line 61: Actual: node::StringEqualNoCase, Expected: node::Calloc
        Line 72: Actual: node::StringEqualNoCaseN, Expected: node::Malloc
        Line 87: Actual: node::ToLower, Expected: node::MaybeStackBuffer
        Line 101: Actual: node::Malloc, Expected: node::MaybeStackBuffer
        Line 109: Actual: node::Calloc, Expected: node::SPrintF
        Line 117: Actual: node::UncheckedMalloc, Expected: node::StringEqualNoCase
        Line 125: Actual: node::UncheckedCalloc, Expected: node::StringEqualNoCaseN
        Line 134: Actual: node::MaybeStackBuffer, Expected: node::ToLower
        Line 214: Actual: node::MaybeStackBuffer, Expected: node::UncheckedCalloc
        Line 257: Actual: node::SPrintF, Expected: node::UncheckedMalloc
using statements aren't sorted in 'test/cctest/test_base64.cc'.
        Line 8: Actual: node::base64_encode, Expected: node::base64_decode
        Line 9: Actual: node::base64_decode, Expected: node::base64_encode
using statements aren't sorted in 'test/embedding/embedtest.cc'.
        Line 19: Actual: v8::Value, Expected: v8::V8
        Line 20: Actual: v8::V8, Expected: v8::Value
make: *** [tools/.cpplintstamp] Error 1
-bash-4.2$

Fix checkimports.py so that all passed arguments are checked instead of just the first one.

Opening as a draft to check that our actions/CI jobs fail properly now.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

Close in favour of https://github.com/nodejs/node/pull/34582.

Fix checkimports.py so that all passed arguments are checked instead of just the first one.

Opening as a draft to check that our actions/CI jobs fail properly now.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

I think we may have run out of space again.

I'm seeing lots of "java.io.IOException: No space left on device" messages in the Jenkins system log (https://ci.nodejs.org/log/all).

Updated test-osuosl-aix72-ppc64_be-2. Interestingly ansible_architecture for that host returns chrp instead of ppc64 so I've explicitly set arch for our AIX platforms to be on the safe side.

Verified on Windows VM. Not sure how to write a test for this… I'm quite confused by why our windows tests pass without this - I doubt watchman is installed. Maybe they have some other find?

The test mock child_process so don't actually spawn. https://github.com/richardlau/jest/blob/41436be27aef1b5968d5360062e5599d206f16d8/packages/jest-haste-map/src/crawlers/tests/node.test.js#L11-L35

It looks like you're trying to use a module (jitterbuffer) that isn't compatible with Node.js 12: https://github.com/Rantanen/node-jitterbuffer/issues/15#issuecomment-619159242

Also, let’s fast-track this. We can take care of the non-surfacing weirdnesses after that. :)

👍 to both statements.

It's by design. On Windows that is where npm installs "global" packages (see https://docs.npmjs.com/try-the-latest-stable-version-of-npm#upgrading-on-windows). That directory is put on the path so that you can run commands installed globally (npm install -g ...) by npm.

The leading v here should also be dropped for consistency with the rest of the paragraph.

It's puzzling our CI's (neither Actions or Jenkins) didn't pick that up.

Stripping the leading v off the version numbers kind of precludes the use of the REPLACEME tag (e.g. https://github.com/nodejs/node/commit/eaa9f833098d687ad0c49f96bff0c79650b293b0), or at least means there's the possibility of an inconsistency. The release process replaces REPLACEME instances with a leading v: https://github.com/nodejs/node/blob/master/doc/guides/releases.md#step-3-update-any-replaceme-and-dep00xx-tags-in-the-docs

The nodejs/node-chakracore team has been deleted and no longer exists. Remove from the captured normal security matrix.

Refs: https://github.com/nodejs/admin/issues/526

I've removed the team from the security matrix for both release and test Jenkins. This PR updates the image used in the guide for security releases.

Before: (i.e. the existing static-assets/jenkins-authorization-normal.png but with Jenkins now showing that nodejs*chakracore was not found).

Also, in case there's confusion, this will be the latest Java 8 (it won't jump to, e.g. Java 11 without the variables being manually updated).

The other platforms use package managers and will update accordingly (via the package-upgrade role). https://github.com/nodejs/build/blob/40c08e80c69dd1cafaf395046b68b2908b080658/ansible/roles/java-base/tasks/main.yml#L30-L33

Updates will only occur when someone runs the ansible playbook. I would very much like to avoid having to edit the ansible scripts every time we update Java, which is why I removed hard coded versions and paths.

Fixes: https://github.com/nodejs/build/issues/2393

Replace several duplicated tasks for installing Java from builds provided by AdoptOpenJDK with a set of common tasks.

Remove hardcoded Java release specific paths.

Thanks to @sxa for pointing me at the AdoptOpenJDK API which these changes use to fetch the latest release for Java version being installed.

<details> <summary>An example use of the API</summary>

https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ga?architecture=ppc64le&image_type=jre&jvm_impl=openj9&os=linux&project=jdk&heap_size=normal&page_size=1&sort_method=DEFAULT&sort_order=DESC&vendor=adoptopenjdk

[
    {
        "binaries": [
            {
                "architecture": "ppc64le",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jre",
                "jvm_impl": "openj9",
                "os": "linux",
                "package": {
                    "checksum": "b1c91e757195b87d51027ea97fece00ac1adb9837b055e5f039dd45511fb3c0a",
                    "checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u265-b01_openj9-0.21.0/OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz.sha256.txt",
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u265-b01_openj9-0.21.0/OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz",
                    "name": "OpenJDK8U-jre_ppc64le_linux_openj9_8u265b01_openj9-0.21.0.tar.gz",
                    "size": 48506506
                },
                "project": "jdk",
                "scm_ref": "openj9-0.21.0",
                "updated_at": "2020-07-29T15:39:20Z"
            }
        ],
        "download_count": 466,
        "id": "MDc6UmVsZWFzZTI5MDY1MjIz.h/htfG2PeOnElg==",
        "release_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u265-b01_openj9-0.21.0",
        "release_name": "jdk8u265-b01_openj9-0.21.0",
        "release_type": "ga",
        "timestamp": "2020-07-29T10:03:22Z",
        "updated_at": "2020-07-29T10:03:22Z",
        "vendor": "adoptopenjdk",
        "version_data": {
            "build": 1,
            "major": 8,
            "minor": 0,
            "openjdk_version": "1.8.0_265-b01",
            "security": 265,
            "semver": "8.0.265+1"
        }
    }
]

</details>

I've run the updated scripts against test-ibm-aix71-ppc64_be-1, and test-osuosl-centos7-ppc64_le-1 to update the version of Java used on those. I'll wait for some feedback/reviews before updating the rest.

Updated:

• [ ] release-ibm-aix71-ppc64_be-1
• [ ] release-osuosl-centos7-ppc64_le-1
• [x] test-ibm-aix71-ppc64_be-1
• [ ] test-ibm-aix71-ppc64_be-2
• [ ] test-osuosl-aix72-ppc64_be-2
• [x] test-osuosl-centos7-ppc64_le-1
• [ ] test-osuosl-centos7-ppc64_le-2

but not in https://github.com/orgs/nodejs/teams/security-triage/members which is what this list syncs with.

Synced README.md with ncu-team sync README.md.

Refs: https://github.com/nodejs/Release/issues/585

## 2020-07-29, Version 14.7.0 (Current), @MylesBorins prepared by @ruyadorno

Unfortunately it's going to be a bit too soon for me to promote a release as my key was only added to the readme on 20 July so by the Release WG policy I'd be first eligible to do a release on 3 Aug.

For clarification, this is unflagging on 14.x or the next semver major?

I've adjusted the permissions for https://ci.nodejs.org/job/libuv-test-commit-windows-cmake/ and https://ci.nodejs.org/job/libuv-test-commit-osx-cmake/ to be more in line with what we have for the Node.js jobs, which is that we allow authenticated users (via GitHub) to view the jobs and results. So @slurps-mad-rips you should be able to view them now.

I'll have a look at the other libuv jobs in the morning.

The actions failures are new warnings (treated as errors):

2020-07-28T17:59:21.1359496Z ../src/quic/node_quic_session.cc: In function ‘void node::quic::{anonymous}::QuicSessionOnCertDone(const v8::FunctionCallbackInfo<v8::Value>&)’:
2020-07-28T17:59:21.1455906Z ../src/quic/node_quic_session.cc:2732:16: error: unused variable ‘env’ [-Werror=unused-variable]
2020-07-28T17:59:21.1456744Z    Environment* env = Environment::GetCurrent(args);
2020-07-28T17:59:21.1457123Z                 ^~~
2020-07-28T17:59:21.9743160Z ../src/quic/node_quic_session.cc: In member function ‘virtual void node::quic::JSQuicSessionListener::OnClientHello(const char*, const char*)’:
2020-07-28T17:59:21.9744621Z ../src/quic/node_quic_session.cc:399:55: error: ignoring return value of ‘bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::Array; T = v8::Array]’, declared with attribute warn_unused_result [-Werror=unused-result]
2020-07-28T17:59:21.9745989Z    session()->crypto_context()->hello_ciphers().ToLocal(&ciphers);
2020-07-28T17:59:21.9746893Z    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
2020-07-28T17:59:21.9748732Z ../src/quic/node_quic_session.cc:402:54: error: ignoring return value of ‘bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::String; T = v8::String]’, declared with attribute warn_unused_result [-Werror=unused-result]
2020-07-28T17:59:21.9749778Z      String::NewFromUtf8(env->isolate(), alpn).ToLocal(&alpn_string);
2020-07-28T17:59:21.9749960Z      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
2020-07-28T17:59:21.9750767Z ../src/quic/node_quic_session.cc:405:61: error: ignoring return value of ‘bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::String; T = v8::String]’, declared with attribute warn_unused_result [-Werror=unused-result]
2020-07-28T17:59:21.9751274Z      String::NewFromUtf8(env->isolate(), server_name).ToLocal(&servername);
2020-07-28T17:59:21.9751434Z      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
2020-07-28T17:59:21.9807567Z ../src/quic/node_quic_session.cc: In member function ‘virtual void node::quic::JSQuicSessionListener::OnHandshakeCompleted()’:
2020-07-28T17:59:21.9808402Z ../src/quic/node_quic_session.cc:581:55: error: ignoring return value of ‘bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::Value; T = v8::Value]’, declared with attribute warn_unused_result [-Werror=unused-result]
2020-07-28T17:59:21.9808617Z      crypto::GetValidationErrorReason(env, err).ToLocal(&validationErrorReason);
2020-07-28T17:59:21.9808753Z      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
2020-07-28T17:59:21.9809720Z ../src/quic/node_quic_session.cc:582:53: error: ignoring return value of ‘bool v8::MaybeLocal<T>::ToLocal(v8::Local<S>*) const [with S = v8::Value; T = v8::Value]’, declared with attribute warn_unused_result [-Werror=unused-result]
2020-07-28T17:59:21.9810060Z      crypto::GetValidationErrorCode(env, err).ToLocal(&validationErrorCode);
2020-07-28T17:59:21.9810235Z      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
2020-07-28T17:59:26.2727155Z cc1plus: all warnings being treated as errors

Yes, this one is with me to address nits. This PR does address an issue on AIX but is not urgent as it doesn’t affect Node.js.

We updated ICU in Node.js 12.17.0 to a more recent version (ICU 67.1). If you've previously installed full-icu with an older version of Node.js 12 you will need to reinstall full-icu as unfortunately the data is specific to the version of ICU being used.

cc @nodejs/i18n-api

You're trying to do the same as https://github.com/nodejs/node/issues/31803, which AFAIK is not currently possible due to the internal caching.

The user page in Jenkins shows the groups the user is in as far as Jenkins is concerned, e.g. https://ci.nodejs.org/user/nodejs-github-bot/

I’m not sure. https://issues.jenkins-ci.org/browse/JENKINS-44920 suggests it should work, https://issues.jenkins-ci.org/browse/JENKINS-63051 claims it does not.

If the bot is to have the same permissions as a collaborator, could it not be added to the @nodejs/collaborators team? We don’t, AFAIK, have a good method for restoring permissions after CI lockdown for security releases (https://github.com/nodejs/build/blob/master/doc/jenkins-guide.md#security-releases) other than manually reentering the entries so I would prefer not to have to add more.

Results of running ncu-team sync Security-Team.md from node-core-utils.

Figured this should be a separate issue from https://github.com/nodejs/Release/issues/499 and https://github.com/nodejs/Release/pull/588 for visibility.

I'm being onboarded as a new releaser https://github.com/nodejs/Release/issues/585 and am now at the stage where I've been added to various additional GitHub teams as per https://github.com/nodejs/Release/blob/master/GOVERNANCE.md#adding-new-releasers. This also says:

Have a single, high quality SSH key added to the "dist" user on the primary www server (see below for guidelines regarding SSH key quality). ... The public key can be shared with an existing member of the releasers team to be placed on the www server for access to the "dist" user. The private key should be kept very secure and not shared with anyone. Any actual or suspected compromise of the private key should be reported immediately and the key should be entirely removed from use.

So could someone from @nodejs/releasers please add my public ssh key (https://github.com/richardlau.keys) please?

Thank you.

Figured this should be a separate issue from https://github.com/nodejs/Release/issues/499 and https://github.com/nodejs/Release/pull/588 for visibility.

I'm being onboarded as a new releaser https://github.com/nodejs/Release/issues/585 and am now at the stage where I've been added to various additional GitHub teams as per https://github.com/nodejs/Release/blob/master/GOVERNANCE.md#adding-new-releasers. This also says:

Have a single, high quality SSH key added to the "dist" user on the primary www server (see below for guidelines regarding SSH key quality). ... The public key can be shared with an existing member of the releasers team to be placed on the www server for access to the "dist" user. The private key should be kept very secure and not shared with anyone. Any actual or suspected compromise of the private key should be reported immediately and the key should be entirely removed from use.

So could someone from @nodejs/releasers please add my public ssh key (https://github.com/richardlau.keys) please?

Isn't this https://github.com/nodejs/node/pull/31360?

Now that @richardlau has prepared his first release, this can be merged. I'll be adding Richard to the relevant teams detailed in https://github.com/nodejs/Release/blob/master/GOVERNANCE.md#adding-new-releasers - this includes inviting to the nodejs-private organisation.

FWIW I'm already in the nodejs-private organisation (was added when I joined the Build WG), but I believe I would be added to more teams/repositories in that organization as part of the releaser onboarding.

@dmabupt It looks like the reproducibility of this is low but based on the stress runs (same test run over and over) below we've now seen this on both of the test CI machines (test-iinthecloud-ibmi72-ppc64_be-1 and test-iinthecloud-ibmi72-ppc64_be-2).

Looks like a copy-paste error with the RUN_TESTS parameter for that stress run. I've corrected it and started a rebuild: https://ci.nodejs.org/job/node-stress-single-test/152/

Landed in 3e6b05e1aa.

Avoid building the node binary when building the source tarball. We need a node binary to build the docs, but it doesn't have to be one we build from scratch and can reuse any available node binary.

Skip building the xz compressed tarball in the build-tarball workflow as we only use the gzip compressed tarball in the subsequent build jobs.

This significantly cuts the time for the "build-tarball" job from the "Build from tarball" workflow from ~50mins to ~2mins.

Our release CI shouldn't be affected as the job the builds the source tarball builds the binary tarball first so will always have a built node binary to run.

Here's a test build on the release CI: https://ci-release.nodejs.org/job/iojs+release/6206/ Download: https://nodejs.org/download/test/v15.0.0-test20200724221167a148/

cc @nodejs/build-files

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [x] tests and/or benchmarks are included
• [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [ ] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added
• [ ] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

Refs: https://github.com/nodejs/node/pull/34464

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
• [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

Stress run on test-iinthecloud-ibmi72-ppc64_be-1: https://ci.nodejs.org/job/node-stress-single-test/148/nodes=ibmi72-ppc64/