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

chore: list compiler versions used to build each node version on each platform #1522

Closed
refack opened this issue Oct 10, 2018 · 8 comments
Closed

Comments

@refack
Copy link
Contributor

refack commented Oct 10, 2018

(for new contributors, this one might require some GitHub archaeology)

@tiagorvmartins
Copy link

Hi @refack do you think I can help out in this issue? Thanks :)

@refack
Copy link
Contributor Author

refack commented Nov 23, 2018

Hello @tiagorvmartins, you sure could give it a try 👍

I'll give you some leads.

  1. We started the basis for this kind of list at https://github.com/nodejs/build/blob/master/doc/windows-visualstudio-supported-versions.md
  2. You can see the output of our testing CI runs, for example https://ci.nodejs.org/job/node-daily-master/1361/, more specifically https://ci.nodejs.org/job/node-test-commit-osx/22932/nodes=osx1011/consoleText
    Most of those have a call to print the compiler version (or xcode_version).
  3. The platforms in CI are selected according to this filtering script https://github.com/nodejs/build/blob/master/jenkins/scripts/VersionSelectorScript.groovy (notice it's an exclusion rules)
  4. We setup our platforms with Ansible and the scripts are in https://github.com/nodejs/build/tree/master/ansible

I think if you can do this for node 11, and 12 (which is the current master) that would be amazing.

P.S. ping me here, or on IRC or email is you have any quastions (or if you give up ¯\(ツ)/¯)

@tiagorvmartins
Copy link

tiagorvmartins commented Nov 23, 2018

Thanks for the info @refack , seems quite hard for me for a starting point (first contribution on github here xD), but after a quick investigation can you just clarify me that I only need to update the VersionSelectorScript.groovy with the new hosts from the first list you noted, even though its an exclusion rule there? Or does it involve more work beside it? Thanks!

@refack
Copy link
Contributor Author

refack commented Nov 23, 2018

FTR:

Some more references:

More references about the minimal supported platforms, but we sometimes test & release with newer compilers.

There are older ones but they don't even have the "supported platform list"

@refack
Copy link
Contributor Author

refack commented Nov 23, 2018

Thanks for the info @refack , seems quite hard for me for a starting point (first contribution on github here xD), but after a quick investigation can you just clarify me that I only need to update the VersionSelectorScript.groovy with the new hosts from the first list you noted, even though its an exclusion rule there? Or does it involve more work beside it? Thanks!

What we're looking for here is basically a text document describing in part what VersionSelectorScript.groovy does.
It will help us document and publish parameters that are hidden within Jenkins and Ansible, and help us make sure thing like #1596 are correct.

@tiagorvmartins
Copy link

#1599

@rvagg
Copy link
Member

rvagg commented Nov 24, 2018

Oh I was toying with this yesterday while working on #1596. Here's a Groovy script that will print out what builder is used for releases of any given version of Node:

def result = [:]
def parameters = [:]
def combinations = []

combinations.push([ nodes: 'aix61-ppc64' ])
combinations.push([ nodes: 'centos5-release-32' ])
combinations.push([ nodes: 'centos5-release-64' ])
combinations.push([ nodes: 'centos6-32-gcc48' ])
combinations.push([ nodes: 'builtcentos6-32-gcc6' ])
combinations.push([ nodes: 'centos6-64-gcc48' ])
combinations.push([ nodes: 'centos6-64-gcc6' ])
combinations.push([ nodes: 'centos7-arm64-gcc48' ])
combinations.push([ nodes: 'centos7-arm64-gcc6' ])
combinations.push([ nodes: 'cross-compiler-armv6-gcc-4.9.4' ])
combinations.push([ nodes: 'cross-compiler-armv7-gcc-4.9.4' ])
combinations.push([ nodes: 'debian7-docker-armv7' ])
combinations.push([ nodes: 'osx1010-release-pkg' ])
combinations.push([ nodes: 'osx1010-release-tar' ])
combinations.push([ nodes: 'osx1011-release-pkg' ])
combinations.push([ nodes: 'osx1011-release-tar' ])
combinations.push([ nodes: 'pi1-docker' ])
combinations.push([ nodes: 'ppcbe-ubuntu1404-release-64' ])
combinations.push([ nodes: 'ppcle-ubuntu1404-release-64' ])
combinations.push([ nodes: 'rhel72-s390x-release' ])
combinations.push([ nodes: 'smartos14-release' ])
combinations.push([ nodes: 'smartos15-release' ])
combinations.push([ nodes: 'smartos17-release' ])
combinations.push([ nodes: 'builtvs2013-x64' ])
combinations.push([ nodes: 'builtvs2013-x86' ])
combinations.push([ nodes: 'vs2015-x64' ])
combinations.push([ nodes: 'vs2015-x86' ])
combinations.push([ nodes: 'vs2017-x64' ])
combinations.push([ nodes: 'vs2017-x86' ])

parameters['NODEJS_MAJOR_VERSION'] = '10'

Binding binding = new Binding()
binding.setVariable('result', result)
binding.setVariable('parameters', parameters)
binding.setVariable('combinations', combinations)
binding.setVariable('buildType', 'release')
new GroovyShell(binding).evaluate(new File('VersionSelectorScript.groovy'))

result.nodes.each{
  println it
}

You get the following for 10:

[nodes:vs2017-x86]
[nodes:vs2017-x64]
[nodes:builtvs2013-x86]
[nodes:builtvs2013-x64]
[nodes:smartos17-release]
[nodes:rhel72-s390x-release]
[nodes:ppcle-ubuntu1404-release-64]
[nodes:osx1010-release-tar]
[nodes:osx1010-release-pkg]
[nodes:cross-compiler-armv7-gcc-4.9.4]
[nodes:cross-compiler-armv6-gcc-4.9.4]
[nodes:centos7-arm64-gcc6]
[nodes:centos6-64-gcc6]
[nodes:aix61-ppc64]

It's just not quite useful enough to feed into something like #1596, but there's potential here for something.

@github-actions
Copy link

github-actions bot commented Mar 7, 2020

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

@github-actions github-actions bot added the stale label Mar 7, 2020
@github-actions github-actions bot closed this as completed Apr 7, 2020
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