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

update NODE_VERSION choices for nodereport-continuous-integration #1421

Closed
2 tasks done
richardlau opened this issue Jul 31, 2018 · 20 comments
Closed
2 tasks done

update NODE_VERSION choices for nodereport-continuous-integration #1421

richardlau opened this issue Jul 31, 2018 · 20 comments

Comments

@richardlau
Copy link
Member

richardlau commented Jul 31, 2018

Current choices for NODE_VERSION in https://ci.nodejs.org/view/post-mortem/job/nodereport-continuous-integration/ are:

  • v9.0.0-nightly
  • v4
  • v5
  • v6
  • v7
  • v8

This issue tracks the following changes:

  • Add v10
  • Replace v9.0.0-nightly with v11.0.0-nightly

Note that currently node-report is reported broken on Windows after the recent libuv update in v10.7.0 and master (i.e. the v11.0.0 nightlies): nodejs/node-report#113

@richardlau
Copy link
Member Author

richardlau commented Jul 31, 2018

I believe that I have permissions to save changes to the config for this job (that is, the Save and Apply buttons appear).

@richardlau
Copy link
Member Author

Started https://ci.nodejs.org/job/nodereport-continuous-integration/215/ against Node.js v10. Apart from the expected Windows failures, the following are also failing:

nodereport-continuous-integration » rhel72-s390x completed with result FAILURE
nodereport-continuous-integration » smartos16-64 completed with result FAILURE
nodereport-continuous-integration » ubuntu1404-32 completed with result FAILURE
nodereport-continuous-integration » smartos15-64 completed with result FAILURE
nodereport-continuous-integration » ppcbe-ubuntu1404 completed with result FAILURE
nodereport-continuous-integration » smartos14-64 completed with result FAILURE

I think we need to update the job to be smarter about what platforms to build on. The current job config is using this wonderfully convoluted combination filter:
(MACHINES=="all" || MACHINES.contains(MACHINE)) && !((NODE_VERSION=="v4" || NODE_VERSION=="v5") && (MACHINE.contains("s390") || MACHINE.contains("aix"))) && !((NODE_VERSION=="v6" || NODE_VERSION=="v7") && (MACHINE.contains("smartos15") || MACHINE.contains("smartos16"))) && !((NODE_VERSION.contains("v8")) && (MACHINE.contains("smartos14")))

Maybe this can be replaced with jenkins/scripts/VersionSelectorScript.groovy?

The job may also need to call jenkins/scripts/select-compiler.sh.

@richardlau
Copy link
Member Author

For v11.0.0-nightly: https://ci.nodejs.org/job/nodereport-continuous-integration/216/
Broken everywhere because headers are missing, probably due to #1409 (comment).

@refack
Copy link
Contributor

refack commented Jul 31, 2018

Headers issue should now be resolved https://nodejs.org/download/nightly/v11.0.0-nightly20180731be322bd9ad/?d=10
(?d=10 added to bust the cache, so we need to wait for cache refresh or for tomorrow's job before re-testing )

@refack
Copy link
Contributor

refack commented Jul 31, 2018

https://ci.nodejs.org/job/nodereport-continuous-integration/217/ now has a varity of actual failures. One that is build related is v10-11 do not include linux-32 binaries.

[ /centos6-32-gcc6/, releaseType, gte(10) ], // 32-bit linux for <10 only

@richardlau
Copy link
Member Author

richardlau commented Aug 8, 2018

Update: I'm still looking at this. It looks like there's quite a bit of refactoring I would need to do to the job in terms of parameter/matrix names to be able to use the VersionSelectorScript.

  • Add NODEJS_MAJOR_VERSION parameter (maybe refactor the existing NODE_VERSION parameter).
    int nodeMajorVersion = -1
    if (parameters['NODEJS_MAJOR_VERSION'])
    nodeMajorVersion = parameters['NODEJS_MAJOR_VERSION'].toString().toInteger()
  • Refactor MACHINE axis to nodes
    // NOTE: this assumes that the default "Slaves"->"Name" in the Configuration
    // Matrix is left as "nodes", if it's changed then `it.nodes` below won't work
    // and returning a result with a "nodes" property won't work.
  • Define a buildType, non-release (node-report?).
    // Before running this script, `def buildType = 'release'` or some other value
    // to be able to use the appropriate `buildType` in the exclusions

@mhdawson
Copy link
Member

mhdawson commented Aug 8, 2018

You might look at the job for https://ci.nodejs.org/view/x%20-%20Abi%20stable%20module%20API/job/node-test-node-addon-api/. It most likely needs to run on the same set of Node version/os version combinations.

@richardlau
Copy link
Member Author

Hmm tried to use VersionSelectorScript but getting a permissions error:
e.g. https://ci.nodejs.org/job/nodereport-continuous-integration/226/console

FATAL: script not yet approved for use
org.jenkinsci.plugins.scriptsecurity.scripts.UnapprovedUsageException: script not yet approved for use
	at org.jenkinsci.plugins.scriptsecurity.scripts.ScriptApproval.using(ScriptApproval.java:466)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:343)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript$evaluate.call(Unknown Source)
	at org.jenkinsci.plugins.ScriptRunner.run(ScriptRunner.groovy:71)
	at org.jenkinsci.plugins.ScriptRunner$run.call(Unknown Source)
	at org.jenkinsci.plugins.GroovyScriptMES.decideOrder(GroovyScriptMES.groovy:62)
	at org.jenkinsci.plugins.GroovyScriptMES$decideOrder.callCurrent(Unknown Source)
	at org.jenkinsci.plugins.BaseMES.run(BaseMES.groovy:51)
	at hudson.matrix.MatrixBuild$MatrixBuildExecution.doRun(MatrixBuild.java:375)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
	at hudson.model.Run.execute(Run.java:1798)
	at hudson.matrix.MatrixBuild.run(MatrixBuild.java:323)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)

@richardlau
Copy link
Member Author

Thanks to @refack for sorting the permissions.

@richardlau
Copy link
Member Author

With Node 10: https://ci.nodejs.org/job/nodereport-continuous-integration/228/

image

rhel72-s390x failed to run node

+ node -v
node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)

smartos16-64 failed to run node

+ node -v
ld.so.1: node: fatal: relocation error: file /home/iojs/build/workspace/nodereport-continuous-integration/nodes/smartos16-64/node-v10.9.0-sunos-x64/bin/node: symbol _ZTVNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE: referenced symbol not found
/var/tmp/jenkins4379535167751811945.sh: line 17: 82192: Killed

ubuntu1404-32 not skipped (probably an issue for the VersionSelectorScript).
Windows failures are expected (nodejs/node-report#113).

@richardlau
Copy link
Member Author

Node.js v11.0.0-nightly failed due to missing headers tarball (and missing mac os binaries): https://ci.nodejs.org/job/nodereport-continuous-integration/230/

@mhdawson
Copy link
Member

Sounds like the invocation of the compiler selection script is needed to address the GLIBCXX issue, and likely needs the addition from #1265 (which I hope to land soo, just want to be very careful as it would have broken all of our release binaries in its first version :)).

@richardlau
Copy link
Member Author

ubuntu1404-32 not skipped (probably an issue for the VersionSelectorScript).

Being addressed in #1498.

@richardlau
Copy link
Member Author

Sounds like the invocation of the compiler selection script is needed to address the GLIBCXX issue, and likely needs the addition from #1265 (which I hope to land soo, just want to be very careful as it would have broken all of our release binaries in its first version :)).

Definitely looks like we'll need #1265.

https://ci.nodejs.org/job/nodereport-continuous-integration/233/nodes=rhel72-s390x/console

+ rm -rf build
+ git clone https://github.com/nodejs/build.git
Cloning into 'build'...
+ . ./build/jenkins/scripts/select-compiler.sh
++ '[' '' '!=' DONT ']'
++ case $NODE_NAME in
++ SELECT_ARCH=S390X
++ '[' S390X = PPC64LE ']'
++ '[' S390X = S390X ']'
++ export COMPILER_LEVEL=
++ COMPILER_LEVEL=
+++ python tools/getnodeversion.py
python: can't open file 'tools/getnodeversion.py': [Errno 2] No such file or directory
++ NODE_VERSION=
Build step 'Conditional steps (multiple)' marked build as failure

@richardlau
Copy link
Member Author

Now that #1265 has been merged we have the following for Node.js 10:
https://ci.nodejs.org/job/nodereport-continuous-integration/235/
image

Windows failures are expected (nodejs/node-report#113).

The smartos16-64 failure looks to be the following https://github.com/nodejs/node/blob/master/BUILDING.md#fn1:

1: The gcc4.8-libs package needs to be installed, because node binaries have been built with GCC 4.8, for which runtime libraries are not installed by default. For these node versions, the recommended binaries are the ones available in pkgsrc, not the one available from nodejs.org. Note that the binaries downloaded from the pkgsrc repositories are not officially supported by the Node.js project, and instead are supported by Joyent. SmartOS images >= 16.4 are not supported because GCC 4.8 runtime libraries are not available in their pkgsrc repository

@richardlau
Copy link
Member Author

With Node.js 8:
https://ci.nodejs.org/job/nodereport-continuous-integration/236/
image

🎉

@mhdawson
Copy link
Member

mhdawson commented Oct 5, 2018

@richardlau if you look at the build job for n-api we only tests certain node versions on certain smartos images. Is that possibly the issue?

@richardlau
Copy link
Member Author

I've removed smartos16-64 from the build matrix until #1519 is resolved. We still have coverage on smartos15-64 and smartos17-64.

One final build: https://ci.nodejs.org/job/nodereport-continuous-integration/257/
If everything passes apart from the expected Windows failures then I'll close this out.

@richardlau
Copy link
Member Author

One final build: https://ci.nodejs.org/job/nodereport-continuous-integration/257/
If everything passes apart from the expected Windows failures then I'll close this out.

All green apart from Windows (expected):
image

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

No branches or pull requests

3 participants