Testing autopublish.meteor.com

[splendido]

No description provided.

[dandv]

Nice UI!

[jlukic]

👍

[splendido]

Hi @jlukic,
seeing your thumb up here is a real pleasure!

...please feel free to advice about anything you might notice you would have done differently ;-)

[splendido]

Thank you @rgoomar and @zimme for testing this out!
...and it seems everything went good at the first time :)

Anything you'd like to change/add/report?

[deanrad]

Looks intriguing, I'll try it out with octokat.js

[splendido]

@chicagogrooves: Let us know your feedback ;-)

[trusktr]

Does it work with binary builds yet?

[splendido]

@trusktr at the moment there's nothing to autodetect binary packages, but we could (manually?) mark some subscritpion to be published for all architectures (it's just a matter to cycle through available build machines and running meteor publish for arch instead of meteor publish, right?).

Let me know in case you're interested to test it with some package, we'll sort something out!

[trusktr]

@splendido Yeah! This feature on autopublish.meteor.com would an awesome time saver! I'm developing rocket:module right now, and it requires binary builds, and the process is time consuming to do manually. I would totally test it with rocket:module.

[splendido]

any new release coming soon?

[trusktr]

Well, I've been testing things out locally, and I posted some 0.x.x releases on Atmosphere in order to test the publish build process (for example, publishing a package relying on rocket:module to see how the process works, and I've learnt a lot that I otherwise wouldn't have). I didn't know if there was a way to test publishing without actually publishing to Atmosphere. I plan for rocket:[email protected] to be the actual working release. I haven't needed to release anything recently since I haven't needed to test publish builds recently, and I might not have to anymore. I'm down to publish (possibly non-working) 0.x.x versions just to test autopublish.meteor.com.

[splendido]

Ok, let me know when you create your subscription and I'll try to modify the publish procedure to see what happens...
There might be something to change while you try it, so please be aware there might be something odd appening (mostly on the autopublish.meteor.com reporting of publishing operations than for actual publish commands though...)

If you're available for testing, please subscribe rocket:module! :-)

[trusktr]

@splendido I think I've done it. (: I'm not sure if anything has happened.

[splendido]

I had to approve your hook and subscription first...
So I guess the trigger received by autopublish was ignored ;-)

Please give me a bit of time to review the publish process to cycle through available architectures...

[trusktr]

@splendido Aawwesomme. Do build errors get reported somewhere?

[splendido]

yes, you can show a log like this, but in this case I'm thinking we should get four different logs, one for each architecture...
...and, also, the result might not be just failure/success but there might be some success and some failures...
Lets see...

[splendido]

@trusktr, just a stupid question:
should a regular meteor publish be run before the others meteor publish-for-arch?

[trusktr]

@splendido When you try to meteor publish a package with binary builds, you'll get a message like this one with instructions on what to do next: https://forums.meteor.com/t/automatically-publishing-a-meteor-package-with-binary-code/3637

[trusktr]

I added the meteorpublish user to the rocket organization. Do you have access to that user? If so you can clone https://github.com/trusktr/rocket-module and try meteor publish. I can add you as maintainer to rocket:module too. Let me know. I added you as maintainer.

[splendido]

ok, I've seen it. See also #24
But so, the first meteor publishis not necessary? Could we run directly meteor publish-for-arch without the first meteor publish?
I might be ready in a minute if you'd like to test it out...
...I'm going to trigger four different publish, each one for a different architecture, so that we can get a log for each publish operation.
The only problem would be retriggering just some out of the four in case something go wrong...
At the moment only admin users see a button to re-trigger a publish operation, but since the code for a particular release cannot be changed (or could it??) I think there is no point in letting a user re-trigger a failing publish...

Having meteorpublish in the rocket organization is enough, thanks!

[trusktr]

Well, the thing is that meteor publish-for-arch has to be run in the OS that the binary is compiled for, so, for example, you have to run meteor admin get-machine os.windows.x86_32 which puts SSHes you into a build machine hosted by Meteor, then in that machine you have to run meteor publish-for-arch. You have to run meteor publish-for-arch in each machine.

[splendido]

Could you try to make a new release?
I'd say everything's ready for the first automated publish for a binary package!
...this would make a bit of story for the Meteor community! Wouldn't it? ;-)

[trusktr]

Yeah, once meteor publish has been run, that source code has been sent to Meteor/Atmosphere, and then any time you run meteor publish-for-arch in any machine, it builds based on that submitted source code which cannot be modified (I tried that 😆). The only solution is to meteor publish another version as far as I know.

It'd be cool if (since the package requires a binary build) It'd let you change the source until at least one successful build, to fix errors. <-- @glasser

[trusktr]

Yeah, this would be a huge thing for publishing!!

[splendido]

so, wait!
meteor publish first or not?!?!
I'm sorry I got lost! :(

[trusktr]

Yeah, meteor publish first, then get a machine for each arch, then in each machine run meteor publish-for-arch.

[trusktr]

Hehe, nope! It would be nice if instead of CMD they gave us GitBash (msysgit)!

[splendido]

oopps!
rocket:module was first run on linkux instead of mac...
Let me check the db

[trusktr]

Are you running meteor publish for the first time inside of a machine? Linux 64bit by default?

[trusktr]

Where do we find the package folder in the machine?

[trusktr]

Oh, you're git cloning them!

[splendido]

are you sure you want to know the sequence?! ;-)

1. from the meteor server running autopublish.meteor.com I login into a droplet of mine on DO to run meteor admin get-machine xxx and get the machine specs as a JSON object
2. then I get back to the server and log into the build machine..
3. repeat point 2. a number of time in case of binary pacakges ;-)

[trusktr]

SO what's the "first run"? Is that inside a machine, and you're running meteor publish?

[splendido]

yes, I'm already into a meteor build machine.

[trusktr]

Are you using the first run to detect if the package needs a binary build?

[splendido]

not yet!
...I've marked them by hands for now, but it should easily doable by intercepting the warning on the console :-)

[funkytaco]

I'd like to try this. Thanks. My org is CovertLamp

[splendido]

At the moment we're experiencing some problems with our bot user not being able to log in.
We're already in touch with MDG to solve the problem.

I'll let you know when we'll able to restart the service.

Luca

[dandv]

Has the bot user problem been solved, now that publishbot has replaced the previous user?

Also, does the screencast need an update including autopublish.json?

[zimme]

I think that the bot has only been renamed actually, I haven't heard anything that suggests that the bot user is somewhat different now than before. I saw some issue thread about the bot user being allocated more build time on the meteor servers, but I think that was an older thread.

[jdlubrano]

Hey @splendido,

@dandv recently added me to the nvd3 organization. I would like to give this project a try for the nvd3:nvd3. In the next couple of days I plan to follow your templates for wrapping third-party libraries and apply the necessary changes to https://github.com/MeteorPackaging/nvd3.

Thanks!

[splendido]

these are great news @jdlubrano!
what if we create a new repository called nvd3-wrapper so that we can keep all names for wrapper repos ending with -wrapper?
...I'll create the new one right now ;-)

[splendido]

@funkytaco you should be good to go now.
Feel free to test publishing your packages with autopublish.meteor.com

[benjick]

Meep meep: https://autopublish.meteor.com/log/XNZA8WNvzoAMyAwzN

[deanrad]

Hey there - I'm now officially trying to integrate this library: https://github.com/deanius/dependito/tags.

Of course, I didn't fully read the instructions until afterwards, and while I've added packagebot as a contributor to the meteor admin, I didn't create a fork in the MeteorPackaging org - is that still necessary ? Just checking to see if all the steps in the documentation are still necessary.

If so, I'll start from the top and do things the right way :)

[splendido]

@benjick I'm sorry the build machine had very little free memory :(
...but now the error is different: see the new log.
I'd say packagebot was not added to the package's maintainers. is this correct?

[splendido]

@deanius if you're trying to create a wrapper package for dependito you should have a look at this page.
I know it might be hard to follow since we still have to harmonize all the docs and there's still old stuff around, but please try to forgive us ;-)

[deanrad]

Thanks @splendido I'll take a look, no sweat its worth the work :)

[benjick]

@splendido oops, my bad! Guess I never used autopublish on this repo before. Thanks!

[sharlayoub]

Nice work

[trusktr]

Greetings @splendido. :]

I don't know what changed, but ever since Meteor 1.2 (don't know if that's coincidence or not), I haven't needed to do arch-specific builds of rocket:module, so I haven't really had a need to look into autopublish because rocket:module is really the only thing I'm repeatedly publishing to Atmosphere and meteor publish is quick enough now without arch-specific builds.

With ES2016 modules coming out soon, I'll probably end up publishing most things to NPM.

[mathiasrw]

The Library AlaSQL would love to be part of your alpha

[splendido]

Unfortunately autopublish.meteor.com is no more reacheable.
As many of you might already know, *.meteor.com is no more available for deploying demo apps.

Since the last release of Meteor (v1.3) there's official support for ES2016 modules, so I guess this means there's no more need for things like autopublish.meteor.com.

[dandv]

@splendido: thank you so much for all your work. Even though autopublish is no longer needed, I believe it played a crucial role in putting pressure on the core Meteor team to make it possible to use npm modules directly.

Just like other shims, by becoming unnecessary, autopublish ultimately proved to be successful.

[splendido]

Thank you @dandv for the kind words, really appreciated!

...but don't forget the initiative about official wrapper packages was sopported by you essentially! ;-)
I think it's been a great experience, both for the project itself and for the community collaboration and cooperation!