We don't have a way to HCP a changed set of plugins or platforms, so
just exit and ask the user to re-run. There are probably some cases
where we don't have to exit (e.g. if you add the android platform, we
probably don't need to exit out of 'meteor run ios'), but we exit in all
cases for simplicity.
So stop giving tests a way to force-throw it (might break springboard
test; fix this before merging) and stop catching it.
(release.load now just does a single sqlite query!)
It used to need buildmessage because catalog.official.getReleaseVersion
used to be capable of rebuilding local packages. Now it can't! Simplify
all call sites.
Note that buildmessage was not actually used to express "no such
release", before or now.
The test was failing because it was written to run against the real
local warehouse, instead of a stubbed one. When initializing the
Sandbox with an explicit warehouse, the test failed because of
incorrect logic piping the right path to the packages database
(in this case "test-packages.data.db" instead of "packages.data.db").
Unfortunately, the test still fails -- this time potentially due to a bug:
After publishing the package for the first time with `--create`,
the next step tries to update but gets the following error:
There is no package named test:i1iyhj. If you are creating a
new package, use the --create flag.
If we don't clean up the tarball, then the following command (`meteor
build`) fails ("Couldn't create tarball"), but for some reason still
exits with code 0. So we then go on to successfully untar the output of
`meteor build`. If we clean up the tarball from `meteor bundle`, we at
least catch the failure by trying to untar a nonexistent file.
The client cache in sql-land was broken: it sent over the wrong sync token as the default.
This meant that the server thought that this was a much older client. As a result, any
0.9.3+ packages with '_' or '||' in their versions/dependencies were filtered out. There is no
easy way to undo that sort of filtering without deleting the db for a variety of reasons, and if
we are going to delete the db, we might as well increment the version so we don't have to worry about
consistency.
If we fail to install one plugin, then we uninstall all plugins to avoid
awakening the Cordova monsters. Previously, this test was passing
because we were passing a `--settings` argument, which was allowing the
facebookconnect plugin to install, but the build to fail to other,
not-understood reasons. Now that we've removed `--settings`, the plugin
fails to install, which means that all plugins get uninstalled.
Test passes now.
