Unfold `make-ci` in jenkins

[jbergstroem]

We recently introduced a convenience rule to configure, build and test node in one makefile step. This is good for $lazy, but bad in terms of feedback; something that got visible while I was working on scripts that notify github of progress. As it is now, we don't know what part of the build process that fails.

I'd like to unfold this again to improve the feedback to a user. The benefit of this being able to update a PR at gihub stating the compile phase failed, three tests failed instead of just failed. The main downside is expanding build steps at Jenkins.

Thoughts?

[orangemocha]

I think that sounds good. We need to be able to experiment / change things in Jenkins quickly anyway.

BTW, the run-ci rule was introduced because v0.x needed to invoke configure with an additional argument IIRC. Please make sure that you still support all branches when you unfold.

[jbergstroem]

Hm, didn't know that. I'll have a deeper look before I do any changes.

[jbergstroem]

so:

$ $(PYTHON) ./configure $(CONFIG_FLAGS)

..can't really see where CONFIG_FLAGS is defined. Guessing jenkins?

[joaocgreis]

I don't know if it is the only use, but at least that's needed for https://ci.nodejs.org/job/iojs+release/

[orangemocha]

I am planning it to also use it to enable debug builds in CI (nodejs/node#3293) as seen in https://ci.nodejs.org/job/orangemocha-test-commit-linux/2/

You could also use it to pass the appropriate flags for v0.x.

[jbergstroem]

I can't see anything stopping us from doing something similar in the configure step; we'd have to move some logic away from the generic build step in jenkins but that would be it.

[rmg]

The problem with changing this target is that either changes need to be backported to previous release branches so the jobs can stay generic or each release branch gets and maintains its own snowflake jenkins job but without the benefit of storing it in that branch.

It's entirely possible these aren't actually problems at the relatively small scale of node (repos * jobs * branches), but that was the perspective I was coming from.

[jbergstroem]

@rmg said:
either changes need to be backported to previous release branches so the jobs can stay generic or each release branch gets and maintains its own snowflake jenkins job

Do they really though? What i would do is take this -- which today is one invoked step in jenkins (slightly different based on which job we have):

$ $(PYTHON) ./configure $(CONFIG_FLAGS)
$ $(MAKE)
$ $(MAKE) test-ci

..then turn that into three jobs. The idea is not to touch anything in the codebase, just split the steps up in jenkins.

For now, lets stick with node-test-* only to avoid any issues then.

[rmg]

$ $(PYTHON) ./configure $(CONFIG_FLAGS)
$ $(MAKE)
$ $(MAKE) test-ci

I haven't kept up with what the jobs are actually doing and what each branch supports. If that's already the lowest common denominator then I have no concerns. :-)

[orangemocha]

It's probably not too often that we need to alter that structure, but when we do then it is a bit of a pain to make sure all branches are updated. If we wanted to move away from that approach, we could consider doing branch-specific logic in Jenkins through if statements in the scripts. This is already the case with this change as run-ci invokes configure with different parameters on v0.x.

I wouldn't go as far as having separate jobs for each branch. Maintaining multiple jobs is pain with the Jenkins UI and we already have different instances for each platform. Having one job for each of platforms * branches combinations would be a nightmare.

[Trott]

@nodejs/build Should this remain open?

[gibfahn]

I don't think we actually still use make-ci, so I think this can be closed.

(if I'm wrong please reopen).