If $METEOR_BINARY_DEP_WORKAROUND is set, then when bundling for a
non-host platform (build/bundle/deploy commands only), if a package has
no server unibuild for the target architecture, use the host
architecture and replace the npm modules with a package.json and
npm-shrinkwrap.json. Also write out a top-level setup.sh script (inside
programs/server) which runs npm install in all such directories.
To support this, we make sure to save the package.json and
npm-shrinkwrap.json files in various intermediate directories in case we
need them later. (We put them inside node_modules because that is what
gets copied from source tree to isopack.)
This is a temporary workaround for an issue that occurs when building
an app that uses Crosswalk.
We usually attempt to copy android-release-unsigned.apk to the root
build dir after a successful release build, but because Crosswalk
depends on native code, the resulting apk is architecture-specific
(android-armv7-release-unsigned.apk and
android-x86-release-unsigned.apk).
For now, I’m just adding a check so we don’t throw ENOENT. Built apks
can be found as usual in android/project/build/outputs/apk, they’re
just not copied to the root build dir.
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.
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.
