Request: build for all supported architectures directly on the packages server

[tanis2000]

I've been hitting the wall with my head in the last few days trying to fix all the problems that have arisen while porting my apps to Meteor 0.9.1.1 Most of the problems are due to the new packaging system and a feature that would really make my day would be to let the developer upload his package and then have the packaging server build the binaries for all the different architectures. That way we wouldn't have to rely on package maintainers to upload binaries for all the different architectures and would make it easier for them to just publish without having to spin up different servers just to compile a new release.

[ekatek]

Most of the problems are due to the new packaging system and a feature that would really make my day would be to let the developer upload his package and then have the packaging server build the binaries for all the different architectures.

That's coming, and, in fact, doing that is the intent behind the current system! It is probably not coming tomorrow or this month, but I really hope to get it set up before the end of 2014.

[glasser]

Note that as a workaround for now, you can add other people as maintainers on the package and they can run publish-for-arch for you.

If you are using a Mac and need access to Linux, it's relatively easy to set up a nearly-free AWS EC2 instance to run builds on. Harder to find easy Mac access of course.

And yes, we'd love to make a build farm for Meteor packages. While it's certainly something we will get around to eventually, if community members built one first while we're focusing on other projects we certainly wouldn't be sad.

[tanis2000]

@glasser the workaround isn't working for some of the packages I'm working with. As you have already seen there: https://github.com/meteor/meteor/issues/2554 There's something wrong either with the way packages get built or deployed or even something else because that same package is working fine on OSX, so I'm pretty sure the problem isn't in the source code but rather in the way it gets packaged or resolved by Meteor.

@tmeasday @possibilities since you're the men behind Meteorite and Atmosphere, would you be interested in joining forces to try and put a build server for packages together?

[tmeasday]

Haha. Maybe @arunoda would be interested.

[arunoda]

@tmeasday ha ha. may be atmosphere can build that :D

[tanis2000]

With access to the server where the packages get published at the moment, it could work this way:

• an author publishes a new release of a package
• at the end of the upload a trigger wakes the build servers (at least one for each arch of course)
• the build server receives the package name to build
• the build server grabs the source code of the package, runs a meteor publish-for-arch with special privileges to be able to publish just like it was a maintainer of the package

It doesn't look like rocket science to get something working quickly. But without access to the actual packaging system servers and some real economical support this is really not going to happen.

The most I could get going is watching for new packages, download them, run all of the above but then it would be stuck with no access to publish to the repository. And even then I haven't got the resources necessary to keep the servers running :)

[arunoda]

I hope there is a public API for the packaging server. And it may have triggers. If a user needs to use this farm. Just add the farm as a maintainer.

Then farm can decided whether he has authority to do and build and publish it.

---

Arunoda Susiripala

@arunoda http://twitter.com/arunoda http://gplus.to/arunodahttps://github.com/arunoda http://www.linkedin.com/in/arunoda

On Thu, Sep 11, 2014 at 1:55 PM, Valerio Santinelli < notifications@github.com> wrote:

With access to the server where the packages get published at the moment, it could work this way:

• an author publishes a new release of a package
• at the end of the upload a trigger wakes the build servers (at least one for each arch of course)
• the build server receives the package name to build
• the build server grabs the source code of the package, runs a meteor publish-for-arch with special privileges to be able to publish just like it was a maintainer of the package

It doesn't look like rocket science to get something working quickly. But without access to the actual packaging system servers and some real economical support this is really not going to happen.

The most I could get going is watching for new packages, download them, run all of the above but then it would be stuck with no access to publish to the repository. And even then I haven't got the resources necessary to keep the servers running :)

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-55234270.

[raix]

@arunoda you could create a connection to packages.meteor.com and subscribe to "packages" - var foo = new Meteor.Collection('packages'); and add an observer.

Then have devs login to an famer app "hay meteor" and set the binary packages to farm.

Have a node app on linux 32/64 + windows lookup next package to publish arch and have it call a method setting the package done or failed.

Only problem is doing auth on the meteor cli tool without passing on the password - not sure about this.

[arunoda]

thanks @raix. I didn't knew about packages.meteor.com

I think meteor uses ~/.meteorsession file to check the auth. May be we can use that. Or may do something.

[tanis2000]

Now that's nice.

    var connection = DDP.connect("https://packages.meteor.com");
    connection.subscribe("packages", {onReady:function() {
            var Packages = new Meteor.Collection("packages", { connection: connection });
            var list = Packages.find({});
            var p = list.fetch();
            console.log(p);
        }
    });

works a charm.

I suppose you could just feed the password through stdin to the meteor cli when asking for it, unless the token has already been saved ~/.meteorsession

[arunoda]

Yeah. Passing it via stdin should work.

On Thursday, September 11, 2014, Valerio Santinelli < notifications@github.com> wrote:

Now that's nice.

var connection = DDP.connect("https://packages.meteor.com");
connection.subscribe("packages", {onReady:function() {
        var Packages = new Meteor.Collection("packages", { connection: connection });
        var list = Packages.find({});
        var p = list.fetch();
        console.log(p);
    }
});

works a charm.

I suppose you could just feed the password through stdin to the meteor cli when asking for it, unless the token has already been saved ~/.meteorsession

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-55250321.

---

Arunoda Susiripala

@arunoda http://twitter.com/arunoda http://gplus.to/arunodahttps://github.com/arunoda http://www.linkedin.com/in/arunoda

[raix]

If meteor would sponsor server instances ill lent a hand, shouldnt take more than a couple of hours to get up an running. Im not too keen on storing the user password, but its a start.

[tanis2000]

@raix considering the problems I hit with the various Linux distro, it would be much better to drop this whole publish-for-arch madness!

Have a look there https://groups.google.com/forum/#!topic/meteor-core/Fpc1SYTLOz0 and there https://github.com/meteor/meteor/issues/2554#issuecomment-55267019

[arunoda]

agree on that.

---

Arunoda Susiripala

@arunoda http://twitter.com/arunoda http://gplus.to/arunodahttps://github.com/arunoda http://www.linkedin.com/in/arunoda

On Thu, Sep 11, 2014 at 8:39 PM, Valerio Santinelli < notifications@github.com> wrote:

@raix https://github.com/raix considering the problems I hit with the various Linux distro, it would be much better to drop this whole publish-for-arch madness!

Have a look there https://groups.google.com/forum/#!topic/meteor-core/Fpc1SYTLOz0 and there #2554 (comment) https://github.com/meteor/meteor/issues/2554#issuecomment-55267019

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-55277790.

[estark37]

Please include some containerization or other form of isolation in the minimum viable build farm! Building packages involves running arbitrary code from any user in the world. :) @raix @arunoda

[tanis2000]

Since this issue is more about the way packages get bundled, I'm adding my comments from a different issue.

I discovered a new problem with the various architectures. I removed the nemo64:translator@0.6.11 and added nemo64:cldr@2.2.1 instead. I run meteor and here's what I think might be the culprit:

W20140911-15:32:28.711(2)? (STDERR)
W20140911-15:32:28.980(2)? (STDERR) /home/tanis/.meteor/packages/meteor-tool/.1.0.28.u858sv++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173
W20140911-15:32:28.981(2)? (STDERR)                         throw(ex);
W20140911-15:32:28.982(2)? (STDERR)                               ^
W20140911-15:32:28.982(2)? (STDERR) Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/build/Release/xmljs.node)
W20140911-15:32:28.983(2)? (STDERR)     at Module.load (module.js:356:32)
W20140911-15:32:28.984(2)? (STDERR)     at Function.Module._load (module.js:312:12)
W20140911-15:32:28.984(2)? (STDERR)     at Module.require (module.js:364:17)
W20140911-15:32:28.985(2)? (STDERR)     at require (module.js:380:17)
W20140911-15:32:28.985(2)? (STDERR)     at bindings (/home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/node_modules/bindings/bindings.js:74:15)
W20140911-15:32:28.985(2)? (STDERR)     at Object.<anonymous> (/home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/lib/bindings.js:1:99)
W20140911-15:32:28.986(2)? (STDERR)     at Module._compile (module.js:456:26)
W20140911-15:32:28.987(2)? (STDERR)     at Object.Module._extensions..js (module.js:474:10)
W20140911-15:32:28.987(2)? (STDERR)     at Module.load (module.js:356:32)
W20140911-15:32:28.988(2)? (STDERR)     at Function.Module._load (module.js:312:12)
=> Exited with code: 8

Looking at my version of GLIBC I can see that I'm at 2.13 and not at 2.14

tanis@samantha:~/test-translator$ ls -al /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 26 23:10 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.13.so

Here's what happened. Who published the Linux 64 version of nemo64:cldr did it from an Ubuntu 14.04 that runs with GLIBC 2.14 so the binary got linked to that version.

This opens up yet another can of worms IMHO. When it comes to binary packages you can't rely on just one package per architecture as the same architecture with a different GLIBC would not work.

Wouldn't it be better if Meteor itself resolved the dependencies and compiled the correct packages directly on the box the app is being run on?

[raix]

agree with @tanis2000 I've done some investigation too, It would make sense to use the publish-for-arch algorithm when needed at startup instead of publishing this it would be generated locally - the app could do a check to see if the system os has changed if so then recreate binaries. If adding a binary package it too should trigger a run.

This would solve:

• os inconsistencies
• having a server farm

@estark37 I did play around with the concept of adding a maintainer "createbinaryarch" to binary packages. But this is a problem too because a script could read the .meteorsession etc.. The worker could create a new user on the server eg. matching the prefix and do meteor login - but this would require that the instance knew the meteor devs password. Thinking about the complications of having to maintain passwords and transfer them from task server to worker is not ideal. This could be solved by introducing a key pr. instance etc. - so the amount of work and maintenance in a solution like that is pretty hard to justify - I'm not going to dig deeper into this.

[mitar]

I think that it is not enough to add server farms as maintainers. There should be another permission where the user cannot create new versions of a package, but can upload binaries for architecture.

[tanis2000]

@raix @arunoda @glasser If MDG is up for sponsoring the costs of the instances, I'm up for lending a hand as well.

@mitar I agree that there should be a specific permission for the build farm so that it doesn't mess up with new versions and such.

I'd also like to have an official build server that actually builds for all the archs for all of the binary packages without having the maintainer to add explicit permissions for his package. That way, as a user, if the maintainer forgets to do so or just doesn't want to, I'll still be able to grab some official binaries.

[raix]

@tanis2000 So if we introduced a special role for packages allowing only publish-for-arch - Well - I'm just thinking loud here... Why not let all users be able to do that instead? This way the build tool could actually publish-for-arch even for users not logged in - instead of printing out the error message... I'm just saying that the user is no where near the package code, its just the platform specific binaries. cc @estark37

[tanis2000]

@raix as long as the sources are checked out from a trusted environment (being it the author's git repo or Meteor's packages server or any other trusted place) and the binaries built by the official build server, then yeah, there would be no need for special permissions or for a special user to be added to the maintainers of the package. It would make things even easier.

[raix]

@tanis2000 just to be clear, I dont think we need the build server/farm - if a user adds/uses a package on a new arch meteor should auto publish for arch. Again if the meteor tool could generate the binaries locally for the app to use it would be the simplest / safest. If a package dont support a certain platform we should have a way to declaring this in package.js

[tanis2000]

@raix I get your point and I like it because it makes things simpler but @mitar raised some security concerns as a user could hijack the building process and substitute the source code with his own code and publish a modified version of the original source as a binary and no one could tell it.

[ekatek]

Found this thread while looking around for examples of architecture issues -- we are on our way to having a meteor-run build farm, but we wanted to release things gradually (to better test them in the wild) and earlier rather than later.

So, we don't automatically build stuff yet, but I want to post here to urge trying out 'meteor admin get-machine' in release 1.0-rc.2 to get an secure shell to a meteor build machine, which you can then use to publish-for-arch. The more people we have using it and testing it out, the quicker we are likely to feel safe integrating it into the build process by default. :D Thanks so much for your patience!

[raix]

Hi @ekatek I've just tested so a few things that come to my mind is that its a shared instances, we login as meteor - and then publish-for-arch logging in - an important note would be to remember to do meteor logout afterwards.

I've tested publishing a new version and famono now includes all the binaries since extracting that was apparently an antipattern, results of the publish-for-arch on your machines: os.osx.x86_64 - seems to work ok since its complaining that I've already published for this arch os.linux.x86_64 - seems ok since its publishing os.linux.x86_32 - Fails - it states that I've already published for this arch - but I kinda havent

$ getconf LONG_BIT results look correct on the instances.

[ekatek]

Logging out should not be needed -- the machine/VM gets re-imaged before it is reused. (Or, rather, the VM gets destroyed and we start a new VM, and the machine gets released into the AWS machine pool, so either way, the next time it is used, it is a fresh machine). We would never pass a 'used' machine to someone else: as you point out, that would be dangerous if they forgot to log out (for example) and we have a lot of concern invested in, well, keeping things like meteor accounts secure. :)

os.linux.x86_32 - Fails - it states that I've already published for this arch - but I kinda haven't Huh, that's certainly interesting. I'll try to look into that.

Thanks so much for helping with this!

On Tue, Oct 21, 2014 at 12:28 AM, Morten N.O. Nørgaard Henriksen < notifications@github.com> wrote:

Hi @ekatek https://github.com/ekatek I've just tested so a few things that come to my mind is that its a shared instances, we login as meteor - and then publish-for-arch logging in - an important note would be to remember to do meteor logout afterwards.

I've tested publishing a new version and famono now includes all the binaries since extracting those was apparently an antipattern, results of the publish-for-arch on your machines: os.osx.x86_64 - seems to work ok since its complaining that I've already published for this arch os.linux.x86_64 - seems ok since its publishing os.linux.x86_32 - Fails - it states that I've already published for this arch - but I kinda havent

$ getconf LONG_BIT results look correct on the instances.

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-59889174.

[raix]

Ok, so instances are locked. Btw. Why does one have to login manually on the server 'meteor login'? (Isnt it possible for the local meteor to do th meteor login on the server for the user some how?)

[ekatek]

Why does one have to login manually on the server 'meteor login'?

Right now, the server basically allocates a pre-imaged machine and passes in some credentials that we use to SSH in. The build machine itself doesn't know what meteor account it ends up assigned to. I am sure that there is a workaround for this: it is kind of a weird workflow. Probably, this isn't going to be fixed for 1.0, but maybe soon after.

On Tue, Oct 21, 2014 at 12:34 PM, Morten N.O. Nørgaard Henriksen < notifications@github.com> wrote:

Ok, so instances are locked. Btw. Why does one have to login manually on the server 'meteor login'? (Isnt it possible for the local meteor to do th meteor login on the server for the user some how?)

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-59984901.

[tanis2000]

@ekatek I was wondering.. how did you manage to get AWS to spin up an OSX box for you?

[arunoda]

Ekate is it possible to pass initial execution command when creating a box. Then let it run. We can do some scripting with that.

That'd be a simple way to automatic building.

On Wednesday, October 22, 2014, Valerio Santinelli notifications@github.com wrote:

@ekatek https://github.com/ekatek I was wondering.. how did you manage to get AWS to spin up an OSX box for you?

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-60094442.

---

Arunoda Susiripala

@arunoda http://twitter.com/arunoda http://gplus.to/arunodahttps://github.com/arunoda http://www.linkedin.com/in/arunoda

[tanis2000]

Trying the following command:

meteor publish-for-arch nemo64:cldr@2.3.0

throws the following error:

/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173
                        throw(ex);
                              ^
TypeError: Object RemoteCatalog has no method 'getReleaseWithTool'
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands-packages.js:486:28
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:254:13
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:247:29
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:245:18
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:236:23
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at Object.capture (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:235:19)
    at main.registerCommand.name [as func] (/Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands-packages.js:370:31)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.34.shr54d++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/main.js:1255:23

[raix]

@arunoda I guess one could pipe commands etc. having it integrate in meteor publish pr. default if its a binary package.

[ekatek]

@tanis2000 : Yeah, that's a known issue that will be fixed in 1.0 (by releasing 1.0 -- complicated interplay where 0.9.4 is the latest recommended release and has a bug in it that is not quite wide-spread enough to make a point release). For now, try meteor publish-for-arch nemo64:cldr@2.3.0 --release 1.0-rc.2

@arunoda: Yeah, we don't have a way to pass in a script, but, also, you can pass in the --json flag to get the json output containing the hostname, SSH key, username, etc. So, at that point, it should be pretty easy to script it yourself. (Scripting this ourselves is the sort of thing where there is a lot of tiny UX details that we would have to get right, so we haven't done it yet)

[arunoda]

Thanks ekate. JSON things seems interesting. Great.

On Thursday, October 23, 2014, ekatek notifications@github.com wrote:

@tanis2000 https://github.com/tanis2000 : Yeah, that's a known issue that will be fixed in 1.0 (by releasing 1.0 -- complicated interplay where 0.9.4 is the latest recommended release and has a bug in it that is not quite wide-spread enough to make a point release). For now, try meteor publish-for-arch nemo64:cldr@2.3.0 --release 1.0-rc.2

@arunoda https://github.com/arunoda: Yeah, we don't have a way to pass in a script, but, also, you can pass in the --json flag to get the json output containing the hostname, SSH key, username, etc. So, at that point, it should be pretty easy to script it yourself. (Scripting this ourselves is the sort of thing where there is a lot of tiny UX details that we would have to get right, so we haven't done it yet)

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2569#issuecomment-60153730.

---

Arunoda Susiripala

@arunoda http://twitter.com/arunoda http://gplus.to/arunodahttps://github.com/arunoda http://www.linkedin.com/in/arunoda

[tanis2000]

@ekatek it still doesn't work

meteor publish-for-arch nemo64:cldr@2.3.0 --release 1.0-rc.2

gives the following output:

/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173
                        throw(ex);
                              ^
TypeError: Object RemoteCatalog has no method '_queryAsJSON'
    at _.extend.getReleaseWithTool (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog-remote.js:664:28)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands-packages.js:569:28
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:250:13
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:243:29
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:241:18
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:232:23
    at _.extend.withValue (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at Object.capture (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:231:19)
    at main.registerCommand.name [as func] (/Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/commands-packages.js:453:31)
    at /Users/tanis/.meteor/packages/meteor-tool/.1.0.35-rc.4.hiafjh++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/main.js:1322:23

[splendido]

I've discovered this thread while searching for other stuff but...

I recentrly started autopublish.meteor.com to support and ease the direct integration of 3rd party libraries (see also this discussion).

At the moment I'm running the build process on a VM I have on DigitalOcean, but the long term plan is to get more support from MDG in case the project will be able to get a good momentum...

(We already obtained that the page will never be put to sleep: see this)

So, to wrap up, having (free) access to build machines for the supported architectures would be great to spin the project to a next level. :)

After that, the only missing thing would be having the possibility to do a meteor login on the remote build machine for an arbitrary user for which we had a Meteor Developer Account token.

Is there anything on the roadmap for a Meteor OAuth API?

[glasser]

Since meteor admin get-machine is now released, I'm going to close this issue. (@splendido, does that command work for your purposes?)

[splendido]

@glasser, I know there's a time limit (you can also specify the amount of minutes for the reservation with a --minutes option) and @raix reported he hitted the quota a couple of times while experimenting with mbr

I'm worried that there might be some other quota we'll hit soon in case a good number of packages start to user the service.

Do you think it would be a problem requesting e new VM for every new build operation to be spawned? ...in case it'd be always the same user requesting them, is there some other limitation we should be aware of?

If MDG is comfortable with any (reasonable) number of build machine requests, we can start testing with it. ...lets consider that a number of devs could decide to rely on autopublish.meteor.com to release their packages, even if they don't need to publish for different architectures and they could do it from their console (but we won't have means, nor intentions, to prevent them to enable their packages on autopublish).

Tnx for asking, let me know.

[glasser]

For now, if you're using the build service for legitimate Meteor package building, go ahead, and let us know if you hit limits. We'll see what we can do.

[splendido]

Ok, great, many thanks! I'll let you know

[splendido]

...one more thing @glasser: do you think is there any chance to be able to run meteor admin get-machine directly from the server code of autopublish.meteor.com? Or wuold we need a proxy VM where to run meteor login plus meteor admin get-machine in any case? What's the environment for the deployment on *.meteor.com?

[glasser]

The meteor deploy environment isn't particularly set up to facilitate spawning other jobs in an easy and managed way. (A goal for Galaxy is that it should be.)