-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Use build matrix to run tests in different envs
- Loading branch information
Showing
7 changed files
with
9 additions
and
80 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
46a39c9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Travis have to build the packages for each environment in the matrix? Running Travis is taking ~3 as long now.
46a39c9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, Travis runs a new VM for each build so it has to build everything from scratch. But ya, it's a bummer that it takes 3x as long to run the build.
The one thing I like about this approach is that it isolates test output from the different builds. So we can see at a glance if the UMD build is failing, for example. With the test script approach it's a bit harder to see because I have to scroll through the output.
The best approach would probably be to have 1 build but a more flexible test script that lets us isolate output from different builds more cleanly. So the workflow would be like:
We could probably just add a flag to the test script, kinda like the
--no-website
flag we currently have in the build script. So, e.g.node scripts/test.js --module-format=umd
, or something like that.46a39c9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should wrap the rollup outputs array with some checks for TEST_ENV to only build the desired formats?
46a39c9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timdorr Ya, that'd work great if we decide to keep things in separate processes. Right now I'm leaning toward just doing what they do in the React repo and providing a
--type
flag to allow people to build/test whichever things they want. By default we build/test everything.