Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: split CI rules in Makefile #7317

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 20 additions & 4 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -184,11 +184,25 @@ test-all: test-build test/gc/node_modules/weak/build/Release/weakref.node
test-all-valgrind: test-build
$(PYTHON) tools/test.py --mode=debug,release --valgrind

CI_NATIVE_SUITES := addons
CI_JS_SUITES := doctool known_issues message parallel pseudo-tty sequential

# Build and test addons without building anything else
test-ci-native: | test/addons/.buildstamp
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
--mode=release --flaky-tests=$(FLAKY_TESTS) \
$(TEST_CI_ARGS) $(CI_NATIVE_SUITES)

# This target should not use a native compiler at all
test-ci-js:
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
--mode=release --flaky-tests=$(FLAKY_TESTS) \
$(TEST_CI_ARGS) $(CI_JS_SUITES)

test-ci: | build-addons
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \
--mode=release --flaky-tests=$(FLAKY_TESTS) \
$(TEST_CI_ARGS) addons doctool known_issues message pseudo-tty parallel \
sequential
$(TEST_CI_ARGS) $(CI_NATIVE_SUITES) $(CI_JS_SUITES)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is $(TEST_CI_ARGS) needed here then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it will be used here in any job we currently have. I would still like to keep it because it can be useful when prototyping CI jobs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see what I got wrong, nvm.


test-release: test-build
$(PYTHON) tools/test.py --mode=release
Expand Down Expand Up @@ -299,9 +313,11 @@ docopen: out/doc/api/all.html
docclean:
-rm -rf out/doc

run-ci:
build-ci:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or does this need | build-addons?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building the addons should happen only in the test machine that tests addons. We could add it here and transfer all the output to the test machines, but bandwidth is low so this would be quite slow. The Raspberries that test addons handle it well (compile + test addons is faster than all the other tests divided by 7).

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

run-ci: build-ci
$(MAKE) test-ci

RAWVER=$(shell $(PYTHON) tools/getnodeversion.py)
Expand Down Expand Up @@ -715,4 +731,4 @@ endif
bench-all bench bench-misc bench-array bench-buffer bench-net \
bench-http bench-fs bench-tls cctest run-ci test-v8 test-v8-intl \
test-v8-benchmarks test-v8-all v8 lint-ci bench-ci jslint-ci doc-only \
$(TARBALL)-headers
$(TARBALL)-headers test-ci test-ci-native test-ci-js build-ci