Path to adding a Tier 2 build with pointer compression enabled

[cjihrig]

This is a follow up to nodejs/TSC#790. The project currently creates unofficial builds for Linux with pointer compression enabled. With pointer compression enabled, the main branch appears to pass the test suite (at least on macOS where I tested). From what I can tell, v19 and earlier are not in such good shape.

We are interested in getting pointer compression into the CI, and eventually hopefully get it to Tier 2 status (on Linux would be enough). cc: @nodejs/releasers.

I think the first step would be getting this into the CI so that we can have more confidence in the current unofficial build. Unfortunately, I don't have the slightest idea what needs to happen to add a new CI target - but I am willing to do the work if someone can provide guidance.

cc: @mhdawson @mcollina

[mhdawson]

I think two questions we should get feedback on to start are:

1. @nodejs/tsc would it be ok to have pointer compression only enabled for Linux
2. @nodejs/releasers any concern in respect to adding a compressed pointer release to the shipping binaries?

[RafaelGSS]

As a Node.js TSC and Releaser, I'm +1. I don't see it impacting the release workflow directly. However, might make sense to produce a release candidate for LTS versions first (optional)

[richardlau]

2. @nodejs/releasers any concern in respect to adding a compressed pointer release to the shipping binaries?

Yes, I have concerns about confusion to end users in producing a second Linux download, particularly as I seem to recall concerns about ABI compatibility between regular builds and pointer compression enabled ones (think about ecosystem packages using prebuilds, for example).

[cjihrig]

@richardlau would you feel better about only adding pointer compression to the CI so that we can at least have more confidence in the existing unofficial build?

[richardlau]

@cjihrig my response was specifically to the quoted question. I'm neutral on adding another job to the CI.

[mhdawson]

Adding another job to the CI seems resonable to me as we already have machines of the required type available and my first guess is that we would not need additional machines to support the one extra job.

[cjihrig]

@mhdawson so what would be the next step to add the CI job? I'm happy to help, but don't know where/how to get started.

[mhdawson]

I don't see any objections to adding a CI job, so I'll set up a job Colin can edit/work on and then we can take it from there. It probably will mostly be a clone of some other job.

[mhdawson]

Added this job with @cjihrig - https://ci.nodejs.org/job/node-test-commit-linux-pointer-compression.

Just letting it run to confirm it passes and then will add to the daily main run.

[mhdawson]

To answer a question people might ask we did not add as a containerized build as I was not sure how to do that and only have it run in the nightly.

[mhdawson]

Configured the job so that @cjihrig can edit/modify the job in cases changes/fixes are needed.

[mhdawson]

Had to fixup the addition to the daily main job as it did not run today. Believe it should run next time.

[cjihrig]

@mhdawson thanks for the help getting the pointer compression job into the daily job. It looks like it has passed every time it has run for the past few weeks with the exception of one time when GitHub changed the key.

As a next step, does it make sense to add pointer compression to the CI for pull requests on main (from my testing, v19 and older do not work properly with pointer compression)?

[mhdawson]

The part about only running on v19 and later is one that may require something special. @richardlau I don't think the VersionSelectorSecript can help us on this one right?