This commit does the following:
- Introduces the get-machine command. This command contacts the build farm server
gets back a machine reservation and then opens a secure shell to the machine (Alternatively,
you can ask for a json). This also involved factoring out some commands to deal with authenticated
ddp from package-client into a more general auth-client.
- No longer publish binary builds in publish or publish-release; instead give the user a warning
to run get-machine and then publish-for-arch. Someone could ignore this: --existing-version and
publish-for-arch both publish binary builds, but you need to be at least somewhat familiar with
what you are doing to run them. Hopefully, you are running them from a certified build machine, but
if you are not, then, well, it is your package.
Stuff remaining:
- We are going to have a url to external documentation, but I haven't written it yet.
- We are currently talking to the test-build server, instead of the build server, so mac doesn't
work.
(Neither of those changes require significant tool changes)
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.
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.
also, in self-test, only set $METEOR_PACKAGE_SERVER_URL for the specific
runs that actually want the test server (using a tag) rather than kinda
always by accident
springboarding happens infinitely because of build ids
have to manually bootstrap a tropohouse
fixed some other things:
- store package server token in correct domain
- copy files (eg packages pre-publish) with +x flags
- catalog.getReleaseTrack works
- don't pass release to uniload (Meteor.release will always
end up 'UNILOAD')
- fix building meteor-tool again
- stop supporting apps without .meteor/release
- merging unipackages with tools works
springboarding to warehouse releases totally not supported
