build: run-ci makefile rule

[orangemocha]

Adding a single rule to be called from Jenkins.

Jenkins jobs typically call:
python ./configure
make -j $(getconf _NPROCESSORS_ONLN)
make test-ci

After this change, we can have Jenkins call:
make run-ci -j $(getconf _NPROCESSORS_ONLN)

This allows us to customize how we call configure
for different repos or branches (e.g. joyent\node).

[orangemocha]

cc: @nodejs/build

[rmg]

If configure-ci isn't going to be used directly, maybe roll it into run-ci so it's more obvious that run-ci is part of the "contract"?

[orangemocha]

@rmg: agreed. Amended.

[rmg]

LGTM 👍

[jbergstroem]

Wouldn't -j have to be part of make?

[rmg]

The -j will be propagated automatically via $MAKEFLAGS.

---

EDIT
at least that's how GNU Make works.. I've never actually used another make..

all:
    @$(MAKE) foo
    @$(MAKE) bar
foo bar:
    @echo $@ $(MAKEFLAGS)

$ make
foo
bar

$ make -j 5
foo --jobserver-fds=3,4 -j
bar --jobserver-fds=3,4 -j

[jbergstroem]

Can confirm above behaviour; just wanted to bring it up to make sure. Gmake is required as part of the build, so it should work out.

[orangemocha]

The -j will be propagated automatically via $MAKEFLAGS.

Correct. From the make manual I gathered that it's better to let make manage that setting via MAKEFLAGS, so that it can control the total number of tasks running.

[jbergstroem]

LGTM

[thefourtheye]

Since we are explicitly executing with python, do we still need to use ./?

[orangemocha]

Probably not necessary but it doesn't hurt either, does it? We already invoke it like this in a couple other places in the makefile.

[thefourtheye]

Or, why not just ./configure $(CONFIG_FLAGS)?

[orangemocha]

PYTHON is defined differently on different platforms. On some Jenkins slaves, this needs to be set explicitly via the environment variable.

[orangemocha]

@thefourtheye I am assuming it's ok to land as is. Could you give an explicit +1 or -1? Thanks!

[thefourtheye]

@orangemocha I am not sure if my vote counts, but LGTM as-is 👍

[orangemocha]

Thank you! Landed in 12bc397

[orangemocha]

What would be the process for getting this merged into the next branch?

[thefourtheye]

@orangemocha IIRC, next will be rebased with master, by 3.0.0 release. If you want to do it now, send in another PR targeting next. Why next branch?

[orangemocha]

Why next branch?

So that the Jenkins jobs can switch to using this rule, and cover the next branch as well.

Thanks, I'll follow up on that.

[thefourtheye]

@orangemocha Ah, wait. I see that @trevnorris asked what will be merged to what, here, but the question was not clarified.

[trevnorris]

Just need to merge latest release on master into next. (prefer release b/c it's less likely to have bugs that surface in next). Though eh, only one commit could possibly break. I'll do a merge after I get confirmation that it won't mess anyone else up. Will respond when I do.

[orangemocha]

Great, thank you!

[trevnorris]

Has landed on the next branch.