release nightlies are broken for smartos/master

[jbergstroem]

since we use smartos14 to build nightlies, we have to add 15 builders as well. So;

• smartos13 used for 0.x builds
• smartos14 for 4.x and 6.x
• smartos15 forward

correct, @misterdjules ?

/cc @mhdawson

[misterdjules]

That sounds good to me.

[jbergstroem]

I've added a new worker but we still need the logic to branch based on version. If someone from the jenkins-admins team could help out that'd be great; otherwise I will attempt it later this week.

Note: I've also corrected the labels -- the smartos14 worker is removed from the smartos15 label, meaning we can now (correctly) rely on them.

[mhdawson]

I'll try to take a look at adding the logic probably tomorrow.

[mhdawson]

Testing out first cut in this job https://ci-release.nodejs.org/job/iojs+release-mdawson/nodes=smartos15-release/.

Still some tweaking/testing needed but first run for nightly master is building only on smartos15

[jbergstroem]

@mhdawson while refactoring; if you could remove relying on post-1 and pre-1 that'd be awesome. They are/were used for the 0.10, 0.12 -> smartos13 branching logic.

Also, instead of cat ./foo | grep bar you can just use grep bar ./foo.

[mhdawson]

@jbergstroem ok have tested it out and seems like it is doing the right thing across the different versions. Also fixed up the comments you made.

Can you take a final look and then I'll move over to the release job

[jbergstroem]

if [[ "${SMARTOS_VERSION:0:4}" -eq "2013" && ${MAJOR_VERSION} -lt "4" ]]; then

I don't think iojs 1-3 builds on smartos13. I would stick with MAJOR being 0 for smartos13 and use smartos14 for >=1 >> 4.

[jbergstroem]

Also – slightly nitpick – but seeing how we call getnodeversion.py just below this, we could perhaps just invoke it prior and avoid grepping for MAJOR_VERSION. The checks would use something similar to $NODE_VERSION =~ ^[0] instead.

[mhdawson]

Ok, used

MAJOR_VERSION=$(echo $NODE_VERSION | cut -d '.' -f 1)

to re-use output from getnodeversion.py

Adjustted ranges to that io.js 1-3 would use smartos14

Updated main release job with result so we should be good, now will validate that the next nightly runs ok.

@misterdjules there were no changes to the build part but you might want to validate the binaries just in case.

[jbergstroem]

@misterdjules: possibly stupid question but is there a way of getting smartos major version from the host os? I see it as part of /etc/motd but can't see how to regenerate it. Version seems to be consistent with pkg info, but yeah..

[misterdjules]

possibly stupid question but is there a way of getting smartos major version from the host os? I see it as part of /etc/motd but can't see how to regenerate it. Version seems to be consistent with pkg info, but yeah..

It's a great question, and the answer is unfortunately not obvious.

By "from the host os", do you mean from the virtual machine/zone? That's what I'll assume in my answer.

You can get access to the information about the image that was used to provision a given VM/zone by running the following from within that VM:

$ mdata-get sdc:image_uuid
cc27973c-d64c-11e6-a58d-67e135aa72a8

Then, you can query JPC's CloudAPI (e.g by installing the triton CLI to get some information about that image, including its version name:

➜  ~ triton image get cc27973c-d64c-11e6-a58d-67e135aa72a8 | json version
16.4.0
➜  ~

Note that the version here is the image version, not the underlying hypervisor OS version which can be found by running uname a. I think only the image version is relevant to what you're trying to do here.

[jbergstroem]

@misterdjules yes and yes. Thanks for writing that up; exactly what I was looking for.

[mhdawson]

Ok so job ran ok today, but I missed adding smartos15-release to the list of platforms we should be build on so although smartos was green we did not get a nightly. Have added so next nightly should include.