02:19:37  * jgiquit (Quit: jgi)
02:30:10  * benglquit (Ping timeout: 260 seconds)
02:30:42  * bengljoined
02:58:09  <orangemocha_>thealphanerd: it's not trivial to reuse the job structure to run a different type of test. You could make the type of test run a parameter and have a switch in each script to run different tests based on it
02:58:23  * orangemocha_quit (Read error: Connection reset by peer)
02:59:36  * orangemochajoined
03:04:33  * orangemochaquit (Read error: Connection reset by peer)
03:05:00  * orangemochajoined
03:09:09  * orangemocha_joined
03:16:47  * orangemochaquit (Read error: Connection reset by peer)
05:12:40  * jgijoined
05:38:58  * jgiquit (Quit: jgi)
05:57:49  * rmgquit (Remote host closed the connection)
06:21:07  <jbergstroem>orangemocha_: i'd like to avoid adding two bots to control what gcc toolset we use for some of our slaves. do you think invoking a job with a different label would be a good idea?
06:37:59  <jbergstroem>ehm: SEVERE: I/O error in channel channel
06:41:29  <jbergstroem>ah, might be java16
06:43:23  <jbergstroem>so, according to this centos6 machine slc6-devtoolset installs java-1.6.0?
06:58:44  * rmgjoined
07:06:50  * rmgquit (Ping timeout: 240 seconds)
07:18:21  * rmgjoined
07:19:33  <jbergstroem>sorted it by passing absolute path to the 1.8.0 jdk \o/
07:30:29  <jbergstroem>ok, new centos6/7 slaves at ibm hq online. i'll sunset the other once later once they've had a few builds (just tried one which passed)
08:28:23  * rmgquit (Ping timeout: 250 seconds)
08:28:41  * rmgjoined
09:03:33  <jbergstroem>is there a way to figure out what jobs uses a specific label?
09:26:34  <jbergstroem>I'm starting to believe that the things that helped us when starting to use jenkins (using the admin to set up jobs) are hurting us since it quickly becomes disoriented. Every time a change is made multiple jobs has to edited -- not very grep friendly
09:26:50  <jbergstroem>*becomes disorienting
10:26:13  * rmgquit (Remote host closed the connection)
10:26:46  * rmgjoined
10:31:54  * rmgquit (Ping timeout: 272 seconds)
10:49:06  <joaocgreis>jbergstroem: not that I know of. Let us know if you find it, I've needed that several times as well
10:50:18  <joaocgreis>thealphanerd: take a look at stress-single-test. If you don't mind compile times on some labels being huge, it's as simple as I could make it
11:10:26  <orangemocha_>jbergstroem: I am not sure what you mean by "invoking a job with a different label", can you elaborate?
11:10:45  <orangemocha_>regarding the naming conventions, don't let my last comment stop you from moving forward :)
11:11:23  <orangemocha_>we do use some of the windows machines interchangeably for build and test, and it's done by having them assigned to multiple lables
11:11:27  <orangemocha_>labels
11:11:39  <jbergstroem>orangemocha_: sure. one idea i had was to have one slave instead of two for the centos bots that runs both gcc48 and gcc44. i was hoping to use the invoked label (centos5-64-gcc44 or similar) to do something
11:12:05  <orangemocha_>we do have examples of that
11:12:18  <jbergstroem>oh
11:12:18  <jbergstroem>do you think its a good idea?
11:13:05  <jbergstroem>probably even two labels, centos5 and gcc44
11:13:29  <orangemocha_>yes two labels would make sense
11:13:33  <jbergstroem>if(gcc44) PATH=$(gcc44_path_munger):$PATH ish
11:13:49  <orangemocha_>in terms of it being a good idea, as long as they don't interfere with each other...
11:14:42  <orangemocha_>what happens if you want to run a job on gcc44 and gcc48 labels? I guess the same slave could only pick up one of those at the time, right?
11:15:25  <jbergstroem>yes, and thats a good thing
11:15:33  <jbergstroem>running them in parallel will just be headaches anyway
11:16:29  <jbergstroem>and to finish up the naming thing, i don't really care if its an rpi or rpi2. happy to put it in the description and label it up, but from a deploy perspective it doesn't really matter
11:16:35  <jbergstroem>(my 2c) :)
11:17:01  <orangemocha_>it's bikeshedding at this point :)
11:17:11  <jbergstroem>i know
11:17:13  <orangemocha_>sorry to randomize that thread
11:17:18  <jbergstroem>nah its good
11:17:22  <orangemocha_>in the end, we assign jobs to labels
11:17:25  <jbergstroem>rather get it all out there so we can reference it in a few months
11:17:29  <orangemocha_>so the machine name doesn't matter from that perspective
11:17:39  <orangemocha_>we could give them GUIDs and it would still be ok
11:17:41  <jbergstroem>the machine name will matter as part of ansible
11:17:48  <jbergstroem>that's where i want to head
11:18:16  <jbergstroem>we can essentially do a script which talks to jenkins ci, creates a node, gets the secret, adds to ci firewall and then installs everything
11:18:23  <jbergstroem>just by having host/ip.
11:18:49  <orangemocha_># of executors: 1. That's what should guarantee that multiple toolchains/lables on the same bot don't interfere with each other
11:19:43  <orangemocha_>that would be nice
11:20:15  <jbergstroem>yeah we have that on pretty much all slaves i think
11:20:39  <orangemocha_>I think so
11:22:01  <orangemocha_>thealphanerd: tip: make your own copy of the jobs you want to experiment with. We normally prefix those with our aliases instead of "node-" eg: thealphanerd-test-commit
11:36:19  <jbergstroem>orangemocha_: it'd be trickier doing centos5, gcc44 than centos5-gcc44 though since if i wanted to run both gcc48 and centos5 i'd have an awful lot of logic
11:36:54  <jbergstroem>orangemocha_: plus, as a user it would be harder to understand combining the labels
11:37:20  <jbergstroem>orangemocha_: btw any input on my rsa keys issue? i'd really like to proceed with that
11:37:24  <orangemocha_>agreed
11:38:12  <jbergstroem>orangemocha_: https://github.com/nodejs/build/issues/254
11:43:07  <orangemocha_>shared keys sounds like a good idea. Easier to manage
11:44:09  <orangemocha_>I assume the private key for the test key would need to be stored in Jenkins somewhere?
11:46:53  <orangemocha_> jbergstroem ^
11:47:16  <jbergstroem>it already is through credentias
11:47:19  <jbergstroem>+l
11:47:26  <jbergstroem>so lets just keep that outside of this?
11:47:55  <orangemocha_>outside where?
11:48:49  <jbergstroem>the other keys we'll be distributing and storing in our secrets repo
11:49:00  <jbergstroem>or do you mean that the test-key should be put into jenkins as well?
11:49:48  <orangemocha_>does jenkins need to store the test key?
11:50:06  <orangemocha_>anyway, my thinking is that the secrets repo is fairly hard to compromise
11:50:17  <orangemocha_>but things that are stored in jenkins will be more vulnerable
11:51:12  <orangemocha_>so I am thinking that having a separate key for jenkins might be a good idea
11:57:15  <jbergstroem>joaocgreis: do you use the keys that jenkins store in its credentials for ssh ?
12:09:00  <joaocgreis>jbergstroem: the iojs-Slaves key is used to ssh to the cross-compile server, now that I know about the azure timeout I'll change it back to start.sh
12:09:51  <joaocgreis>the iojs-Github is the key of @nodejs-ci gh user, that has write access to the temp repo
12:11:29  <jbergstroem>what about the keys in /credentials/ ?
12:12:02  <jbergstroem>sorry, i see now;
12:12:43  <jbergstroem>wouldn't it potentially be safer to promote the crossdev-machine to "infra" status (so just a few people can login to it) and store a private key there?
12:22:15  <joaocgreis>not sure. This way the key is stored in jenkins, but it's available in the machine only during the compile job. And the file is only readable in the windows machines, because in linux machines (rpi-cc and master) a ssh-agent is used
12:22:32  <joaocgreis>but having the key only in the infra machines is doable too
12:23:37  <jbergstroem>just thinking of next jenkins security scare
16:28:35  * rmgjoined
16:59:24  * jgijoined
17:50:30  * jgiquit (Quit: jgi)
18:02:28  * jgijoined
18:27:46  * jbergstroemquit (Ping timeout: 240 seconds)
18:28:04  * jbergstroemjoined
19:36:44  <orangemocha_>jbergstroem I am trying to reconnect https://ci.nodejs.org/computer/msft-serialport-win1/
19:37:05  <orangemocha_>but it's behind a proxy and I don't think it has a static ip
19:37:18  <orangemocha_>is it possible to get it through the jenkins firewall?
19:59:14  <jbergstroem>orangemocha_: how wide is the ip range? can we subnet?
21:22:29  <orangemocha_>jbergstroem: only Microsoft Redmond campus ;) but it should be possible
21:32:30  <jbergstroem>orangemocha_: if possible i'd liek to keep the firewall :(
21:48:21  * jgiquit (Quit: jgi)
22:24:38  <jbergstroem>orangemocha_: any subnet is better than no subnet
22:24:47  <orangemocha_>yes yes, working on finding out
22:25:02  <jbergstroem>orangemocha_: also, would we have to update our remote desktop configs based on it? is it like a ddns setup?
22:25:18  <jbergstroem>orangemocha_: if we can do ddns i could probably to use that for iptables too
22:25:49  <orangemocha_>let me find out more. I think it might be inside corpnet
22:28:02  <orangemocha_>btw do I show as orangemocha or orangemocha_ ? I am trying IRCcloud and I see both
22:29:40  <jbergstroem>with underscore
22:29:50  <jbergstroem>[09:29:43] Message(402): orangemocha No such user
22:37:41  * jgijoined
22:53:15  <jbergstroem>doing some memory profiling on our jvm: https://gist.github.com/jbergstroem/2d28759a56b7f99cd54e
22:53:46  <jbergstroem>i'll throw 8 additional gigs to the jvm and avoid messing with the new/old ratios
22:55:12  <jbergstroem>rvagg: are you ok with me looking into removing the -gcc* slaves and use labels to represent gcc verisons instead? I'll PR when it works
23:07:27  <rvagg>jbergstroem: sure, if it works for libuv, that's all we use them for
23:07:39  <jbergstroem>rvagg: yeah i'll test it out
23:07:49  <jbergstroem>introducing a debug vm now. was thinking centos7 4G ?
23:07:59  <jbergstroem>should we set up a new job and hook it up to test-pr ?
23:08:24  <rvagg>sure, sounds like fun
23:08:39  <jbergstroem>i've retired centos6,7 on digtialocean now
23:08:44  * bnoordhuisjoined
23:08:52  <jbergstroem>starting to get more room
23:13:06  <jbergstroem>bnoordhuis: i'll create a new job but won't attach it to test-pr until we move closer to green
23:14:58  <jbergstroem>trott should irc more often
23:17:18  <jbergstroem>rvagg: reckon we should add JOBS, DESTCPU, etc as part of environment to all jenkins init scripts?
23:17:31  <jbergstroem>would sorta mess up cross-compilation