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

mips64el CI #2296

Closed
FlyGoat opened this issue Apr 17, 2020 · 3 comments
Closed

mips64el CI #2296

FlyGoat opened this issue Apr 17, 2020 · 3 comments
Labels

Comments

@FlyGoat
Copy link

FlyGoat commented Apr 17, 2020

Context: nodejs/node#31118

Hi build WG,
We're trying to promote mips64el as an Experimental level supported architecture. For that, we need to set up CI for mips64el.
I can provide two options for that.

First, we can sponsor a build & test machine for node in China, hosted at Beijing Foreign Studies University.

The spec of the machine would be:

  • CPU: Loongson-3B1500 @ 1.3 GHz (8 cores)
  • RAM: 8G DDR3
  • Hard Disk: About 500G?
  • OS: Fedora 21 & 28 or Debian Buster

There is an issue for that option, we can't provide public IPv4, only public IPv6. But we can help with seting up tunnel or sth for IPv4 users to remote access.

The second option is to run mips64el CI in QEMU on node's infrastructure.

qemu-system-mips64el -M malta -cpu 5Kc

Can emulate a regular mips64el machine. Although it is fairly slow, but enough for testing purpose.

Thanks.

@rvagg
Copy link
Member

rvagg commented Apr 17, 2020

Introducing new nodes into CI brings a bunch of problems for the team that would have to be dealt with. The two main ones being: maintenaince of those nodes and assistance fixing bugs as they show up in nodejs/node, turning everyone's builds red.

I think the Build WG would want to know that we have people on-hand to help address infrastructure issues, like we do with the IBM platforms (I know very little about AIX and zOS but I know for sure that there's a team of IBM folks who are on top of problems as soon as they appear). Being Linux, the barrier would be lower for introducing MIPS64el, but a new infrastructure donor brings its own concerns too wrt reliability. Nodes that don't have good reliability can hold up everyone's jobs and cause a lot of frustration.

We also aim for redundancy in our test CI to help with reliability, so at least 2 of each thing is what we shoot for, for some we have more. Would that be practical for BFSU to sponsor?

And if we were to set up a @nodejs/platform-mips54el team with knowledgeable people that (a) know the platform and (b) have some understanding of Node.js, would the nodejs/node contributors have any problem getting someone's attention in a short amount of time when things start to break for reasons they can't figure out?

Lastly, do you have any details on how long Node.js takes to build and run the test suite on one of your machines and/or in qemu? That would be helpful too. We try very hard to keep CI total run times down and are always keenly aware of the slowest platforms. I don't think we're going to be rushing to introduce new platforms that are significantly slower than what we have now. I'd be very interested to know how practical qemu is for this, we've never attempted it for our CI before.

@github-actions
Copy link

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

@github-actions github-actions bot added the stale label Feb 12, 2021
@mhdawson
Copy link
Member

This was answered a while back with no follow up response from the OP. Closing. Please let us know if that was not the right thing to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants