LoongArch to Experimental tier

[shipujin]

What is the problem this feature will solve?

Support growing number of LoongArch based devices

What is the feature you are proposing to solve the problem?

Provide LoongArch release of node-js

What alternatives have you considered?

No response

[shipujin]

unofficial-builds:

• unofficial-builds loong64 18.x: >=18.18.0 Start to build
  nodejs/unofficial-builds@753fbad
  download url: https://unofficial-builds.nodejs.org/download/release/v18.18.0/

• unofficial-builds loong64 20.x: >= 20.5.0 Start to build
  nodejs/unofficial-builds@15034c1
  download url: https://unofficial-builds.nodejs.org/download/release/v20.5.0/

[shipujin]

we have unofficial builds and there is generally a desire to fix those when they go wrong (but it doesn't pass all the test cases yet) are we in a position where we can consider loong64 a valid "experimental tier" platform?
Related: nodejs/node#50086

Best regards~

[shipujin]

Or what conditions and preparations are required for loong64(LoongArch) to become Experimental-tier

[shipujin]

https://github.com/nodejs/node/blob/main/BUILDING.md#strategy

“Experimental: May not compile or test suite may not pass. The core team does not create releases for these platforms. Test failures on experimental platforms do not block releases. Contributions to improve support for these platforms are welcome.”

I can coordinate LoongArch architecture machines, I don't know what configuration of machines can access CI environment?

"Test failures on experimental platforms do not block releases." Will this release a binary version?

Best regards

[mhdawson]

@shipujin are you/your company planning to keep LoongArch working gowing froward? If so knowing that we have people who will be active in fixing/working on issues is a good data point. If so I think we should create a platform-LoongArch team that we can add you/others from your company to.

We don't release official binaries for Experimental platforms. It looks like you already have experimental builds set up which is a way to make binaries available even if they are not official. I assume these are cross compiled right?

Machines that are in our CI generally are:

1. in a remote cloud or datacenter somewhere
2. accessible through SSH
3. able to run Java so that we can connect them to Jenkins

Providing a couple of machines which interested collaborators could ssh into if they are interested in looking at LoongArch issues would be a good start in my opinion.

It would be good to get more thoughts from the @nodejs/build team in terms of willingness to add machines to the envionment/CI.

[shipujin]

@shipujin are you/your company planning to keep LoongArch working gowing froward?

Yes, our company plans to make LoongArch nodejs working gowing froward.

If so knowing that we have people who will be active in fixing/working on issues is a good data point. If so I think we should create a platform-LoongArch team that we can add you/others from your company to.

We are actively fixing/working on issues, Creating platform-LoongArch team is a great thing to do.

We don't release official binaries for Experimental platforms. It looks like you already have experimental builds set up which is a way to make binaries available even if they are not official. I assume these are cross compiled right?

Ok, I see. Yes， unofficial-builds are cross-compiled builds of nodejs

Machines that are in our CI generally are:

1. in a remote cloud or datacenter somewhere
2. accessible through SSH
3. able to run Java so that we can connect them to Jenkins

Our company can provide a LoongArch machine with ssh login.

I can ask the leader to apply for a machine first (later use is not enough, I can apply to the leader for the machine), the physical machine is running in our company's computer room, there are colleagues in the maintenance, after the deployment of the machine, I can email the login method, so that can ssh log in LoongArch deployment nodejs CI environment,

Is it OK in this way? Looking forward to your reply

Providing a couple of machines which interested collaborators could ssh into if they are interested in looking at LoongArch issues would be a good start in my opinion.

Yes, we will provide an ssh login machine, which can be provided to interested partners to log in and experiment with nodejs.

It would be good to get more thoughts from the @nodejs/build team in terms of willingness to add machines to the envionment/CI.

Look forward to more suggestions from @nodejs/build team, so that LoongArch nodejs can be better developed. thank you

Best regards

[sxa]

The question in my mind is what are we expecting to gain from adding it to the CI? In general the test ci is used for building and running all the tests against PRs by collaborators so there are two questions here:

1. What is the outlook for getting the tests passing cleanly? If it was added into the regular CI then we'd want it to run without errors otherwise it will cause problems interpreting the test results potentially resulting in delays to validating PRs.
2. What is the performance of the systems compared to the other architectures (since that affects the execution time of CI jobs)? I suspect that it us unlikely that we could integrate it into the regular CI without having a significant negative impact on the run times of the PR testing.
   Having said that, as Michael says, I'm not against having machines available for interested parties to progress the status of the port and work towards having it in place, and I can't think of any objection, given the assurances above, that it could be moved to being listed as an experimental platform.

[mhdawson]

@sxa what we've often added is a separate nightly job that runs only for the new archicture. I think that would be a first logical step versus the main CI used for all test PRs.

It would give us a sense of how consistently the tests run/pass and and a way to get some of the info like how long the tests runs take versus other platforms etc.

[sxa]

@sxa what we've often added is a separate nightly job that runs only for the new archicture.

Yep if there's a committer with access to the test CI willing to do that then it's an option, and with that approach we can potentially do it natively instead of requiring cross compilation which adds more complexity in a standalone job.

[targos]

I created the @nodejs/platform-loong64 GitHub team and invited @shipujin to it.
Anyone else who would like to be notified about LoongArch stuff?

[shipujin]

I created the @nodejs/platform-loong64 GitHub team and invited @shipujin to it.
Anyone else who would like to be notified about LoongArch stuff?

Thx~, I joined.

Best regards

[targos]

Added to experimental tier in nodejs/node#50172

[shipujin]

Added to experimental tier in nodejs/node#50172

@targos Sorry to reopen this issue,
I would like to discuss here how to put LoongArch machine access nodejs/build CI environment, test machine for LoongArch nodejs.

Best regards

[shipujin]

I re-created the discussion #3540

Best regards

[shipujin]

The question in my mind is what are we expecting to gain from adding it to the CI? In general the test ci is used for building and running all the tests against PRs by collaborators so there are two questions here:

1. What is the outlook for getting the tests passing cleanly? If it was added into the regular CI then we'd want it to run without errors otherwise it will cause problems interpreting the test results potentially resulting in delays to validating PRs.
2. What is the performance of the systems compared to the other architectures (since that affects the execution time of CI jobs)? I suspect that it us unlikely that we could integrate it into the regular CI without having a significant negative impact on the run times of the PR testing.
   Having said that, as Michael says, I'm not against having machines available for interested parties to progress the status of the port and work towards having it in place, and I can't think of any objection, given the assurances above, that it could be moved to being listed as an experimental platform.

Sorry, I've been testing nodejs(main v18. x v20.x), reply late
#3540 (comment)