(IGNORE THIS PR) - HTTPS in package.json / homepage

[phillipj]

Hi there,

please ignore this PR. I'm testing a custom Jenkins job made to report Jenkins CI build statuses inline in PRs. I need an actual PR to play with.

Refs #358

[gdams]

@phillipj thanks for doing this work!

[gdams]

@phillipj it would be nice to just have 3 jobs shown in the pending checks: eg: Jenkins CI: $NODE_VERSION

SO

Jenkins CI: V4 - checking for errors
Jenkins CI: V6 - checking for errors
Jenkins CI: V7 - checking for errors

[phillipj]

@gdams thanks for following along! I assumed you meant $NODE_VERSION since that is what your recent example had.

I'm still experimenting a with the curl / shell scripts executed when job starts/succeeds/fails.

If I find something that works, I'll try to automate one build started resulting in all three Node.js versions tested as you have requested.

[gdams]

yes that's perfect, we don't really want the individual machines to report back, just the overall job :)

[gdams]

@phillipj is there a reason that it links to the osx job rather than the overall job ?

[phillipj]

It seems to push the "started status" for every child job (axis in Jenkins terms) as they are started. I'm still looking, but haven't found the correct Jenkins setting making started status is only reported once by the overall job (matrix in Jenkins terms).

FYI gotta leave soon, might have to continue working on this another day.

[gdams]

It's pretty much there tbh, once the job is finished it reverts to showing the overall job

[gdams]

@phillipj I have set the job up to run citgm on the "$GIT_REMOTE_REF parameter rather than using the $BRANCH parameter

[gdams]

@phillipj this is really cool, and I think it's working fine as is. Lets see if we can get the github-bot to automate kicking off the job with GIT_REMOTE_REF parameter when we give it a certain command I think we are done :)

[phillipj]

Okey, and that works just fine with npm when referencing pull requests too? Gotta leave for today, will pick this up another day. Couldn't find a way for the matrix to report job started.. But that might solve itself if we have to create another layer of jobs here, since we ideally want three versions of Node tested, not just one.

…

On Tue, 28 Feb 2017 at 22:27, George Adams ***@***.***> wrote: @phillipj <https://github.com/phillipj> I have set the job up to run citgm on the pr ref rather than using the $BRANCH parameter — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#375 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLLE2YQn1nnoftpfogdJ-h_FuwHclauks5rhJFXgaJpZM4MO2IN> .

[gdams]

I have just changed it so that instead of installing with NPM we use:

git clone https://github.com/nodejs/citgm.git
cd citgm
git fetch origin $GIT_REMOTE_REF:testBranch
git checkout testBranch
npm install

[phillipj]

I'm not a Jenkins expert, so suggestions getting v4, v6 and v7 triggered automagically would be much appreciated.

First thought that came into mind was getting another level of matrix in the mix, but I might be going in the wrong direction (?).

@jbergstroem any thoughts?

                                       <Build with params>
                            ------------------------------------------
                               /                |                  \
                              /                 |                   \
 (new matrix?)              v4                  v6                  v7
                            |                   |                    |
                        --------            ---------            ---------
                       /        \          /         \          /         \
 (current matrix)  fedora22   debian8   fedora22   debian8   fedora22   debian8

[gdams]

@phillipj There are two ways to do this:

1. Use the jenkins api to automatically kick off the 3 jobs on the PR branch, one on v4, v6 and v7

2. Make a jenkins flow which passes the parameters down to each job, I can do this if you like ?

[gibfahn]

Make a jenkins flow which passes the parameters down to each job, I can do this if you like ?

Of course only a Jenkins Admin can create the job, so @phillipj would have to create a new citgm job. Once that's done we can edit it. EDIT: @mhdawson created one for us.

[gdams]

@phillipj I have set up a pipeline job for the CI job that will run all 3 versions in parallel, all you will need to do is run the job with the git ref as a parameter and it will do all the rest: https://ci.nodejs.org/job/citgm-continuous-integration-pipeline/.

Should just be a case of getting the github-bot to kick off the pipeline with an API request

[phillipj]

Sorry for dropping the ball on this. Haven't had the time to work on this lately, hoping to squeeze in some hours this week tho.

@gdams nice work on the pipeline 👍

So the next step now is triggering that pipeline via the bot by mentioning @nodejs-github-bot in a comment?

[gdams]

yup that would be ideal perhaps by commenting @nodejs-github-bot run CI or something. BUT it can only be by a member of the nodejs/citgm team

[addaleax]

@nodejs-github-bot run CI

[phillipj]

Thx @addaleax 👍 At first glance no webhook request seemed to be delivered to the bot because of that comment.. I'm suspecting the current webhook setup for the bot on this repo doesn't send comment events, which is required for this to work.

I've been testing it with a webhook that sends all events. Though I'm guessing checking the Issue comment checkbox as shown below, should do the trick.

[addaleax]

@nodejs-github-bot run CI

[nodejs-github-bot]

@addaleax build started: https://ci.nodejs.org/job/citgm-continuous-integration-pipeline/