Console.isInteractive() will be false during our Circle CI test runs,
since we set the METEOR_HEADLESS environment variable, so this change
should help prevent spurious test failures like these:
https://circleci.com/gh/meteor/meteor/15305.
- This changes meteor deploy to poll the /version-status/ REST endpoint
in Galaxy for the build and deploy status of the returned version
- Also fixes up a typo in a test
- Currently only configured to use a default polling configuration
- This change also adds a flag called --no-wait which allows users to
specify that they want the deploy command to behave just as before
By my calculations, the sum of the sizes of the individual isopackets was
152MB, and the size of the combined isopacket is now just 36MB. That
remarkable difference goes to show how much duplication of transitive
dependencies was happening before this change.
That's a savings of 116MB for the (uncompressed) size of the meteor-tool
package. In Meteor 1.5.x, the meteor-tool package is about 544MB, but in
Meteor 1.6 it's considerably smaller: 373MB. In other words, this change
should reduce those sizes to 428MB (-21%) and 257MB (-31%), respectively.
If a login token is expired, or no longer valid, make sure that Meteor doesn't
just sit there at a login prompt that the user can't see.
This currently only applies if `headless` mode is enabled, though a follow-up
to this commit might consider setting `headless = true` automatically
in a CI environment using environment variables such as: `CI`, `TRAVIS`,
`JENKINS_URL`, etc., as the npm-registry-client does in a similar way.
See: https://github.com/npm/npm-registry-client/pull/129/filesFixes#8839.
This simple fix prevents the disappointment of trying to deploy your app
but failing because there's a space on the end of the `DEPLOY_HOSTNAME`
environment variable.
`process.env` always contains string values and assigning a property on
`process.env` implicitly converts the value to a string so it should not
be necessary to check if `typeof` is a `string`.
Fixes Dev Experience.
Update the default deploy server from deploy.meteor.com (which no longer
exists) to galaxy.meteor.com. However, if your app's DNS is already
pointed at Galaxy, automatically discover the deploy server's URL.
See meteor/amsterdam#305
"universe" was an old attempt to allow you to run various MDG
servers (Meteor Developer Accounts, the package server, an old version
of the Galaxy deploy server, etc) on localhost and configure the tool to
talk to it not via a bunch of environment variables but via a file
called "universe" at the root of your checkout. Nobody uses this (and
most of the URLs have environment variables for them anyway). Simplify
the code by removing this entirely.
Also remove some more dead code, and a test that claims it only runs if
you have universe set up.
Fixes#4757
Uses environment variable CAFILE (to match NPM) which must contain a fully qualified path to a pem format root certificate to include in the list of trusted root certs.
This additional root certificate will be needed for those behind an SSL inspection proxy which acts as an SSL termination point and resigns the traffic with its own root certificate.
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.)
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.
