UX Changes:
- Added a `--galaxy` option to selftest to run tests against galaxy.
Self-test will NOT run those tests without this option. Self-test will not run any
other tests WITH this option.
The motivation here is two-fold:
- We want to make it easy to use self-test to test Galaxy without running a bunch
of extra tests. At least, we want this right now, while Galaxy is still in development.
- Galaxy is currently pretty unstable&slow; we don't want to run our regular test suite against
Galaxy all the time and slow down the tool development process. Additionally, the environment
variables required by Galaxy are a pain to set.
This is a TEMPORARY situation. Eventually, we will want to either merge the two tests together
(especially once we rotate out Mother...) or we will have a separate unrelated Galaxy test suite
and move a lot of this stuff here. With time, it will also become more obvious what a better default
(run Galaxy tests always/run Galaxy tests never/run non-Galaxy-specific tests against Galaxy) is.
The changes should be pretty self-contained.
- Added some number of environment variables to use with --galaxy tests. This is a bit complicated
and will be documented in
https://mdg.hackpad.com/GalaxyECS-Admin-tasks-RTXJ5YW8pDv#:h=Testing-Galaxy-with-selftest.
Walkthrough:
- galaxy-utls.js contains basic utils for running Galaxy tests. Use environment variables, etc.
- galaxy.js contains the acutal test
- simple-app is an app that responds to HTTP requests and serves some html that we can test to be running
- minor changes to config.js to allow overriding of the domain name
- minor changes to auth.js to allow us to automatically login as the (new) test user and use that
login to start a DDP collection.
- move a function out of deploy-settings.js into test-utils.js
- some minor additions to test-utils.js
Reviewed in https://github.com/meteor/meteor/pull/4997.
Cordova plugin IDs have changed as part of moving to npm. We convert
old plugin IDs to new IDs in the 1.2.0-cordova-changes upgrader, when
adding plugins, and when preparing for build.
We now create a temporary directory with a generated config.xml
to use as a template for creating the Cordova project. This way, we are
not dependent on the contents of cordova-app-hello-world but we base
our initial project state on our own defaults and optionally a
mobile-config.js.
This change was in part motivated by a bug in Cordova where changing
the app name to a version with a different case, on a case insensitive
file system like OS X, means the project will no longer build. Because
our app name on creation was based on the project directory and we
didn’t respect the app name set in mobile-config.js until the first
build, there was always a rename needed, triggering the bug.
This bug affected both the todos and localmarket example apps.
- Refactored code in tools/cordova and introduced CordovaBuilder and
CordovaRunTarget classes
- CordovaRunner now builds and runs the project as part of the main
runner loop
- Some code cleanup and ES2015 conversions
Because netroute is not available on Windows, and I haven’t been able
to find another way to detect the default route there, we try to find
a unique non-internal IPv4 address as a fallback. Also, improve error
reporting in cases we aren’t able to autodetect a unique IP address.
I’ve removed the automatic retry after 2 seconds, because I felt it was
of limited use (if you lose the address you would also have lost the
default route?) and it would slow down error reporting in the common
case where the error persists.
It's very useful to be able to include code only in production. It's
useful for React integration, but presumably also for many apps.
* Add prodOnly boolean flag alongside debugOnly in Package.describe
* Packages the set prodOnly to true auto-depend on isobuild:prod-only
(making them error in the old tool where prodOnly isn't supported)
* The `includeDebug` boolean build option is replaced by a string
named buildMode, which can be 'development' or 'production', just
like minifyMode.
Tested by self-test.
Now instead of calling `catalog.getLatestMainlineVersion` when printing
messages about non-latest versions in `meteor update` with no args,
we use the same logic from `meteor list`.
