Testing autopublish.meteor.com
splendido opened this issue · comments
Nice UI!
👍
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 ;-)
Looks intriguing, I'll try it out with octokat.js
@chicagogrooves: Let us know your feedback ;-)
Does it work with binary builds yet?
@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!
@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.
any new release coming soon?
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:module@1.0.0 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.
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! :-)
@splendido I think I've done it. (: I'm not sure if anything has happened.
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...
@splendido Aawwesomme. Do build errors get reported somewhere?
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...
@trusktr, just a stupid question:
should a regular meteor publish be run before the others meteor publish-for-arch?
@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
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.
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!
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.
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? ;-)
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
Yeah, this would be a huge thing for publishing!!
so, wait!
meteor publish first or not?!?!
I'm sorry I got lost! :(
Yeah, meteor publish first, then get a machine for each arch, then in each machine run meteor publish-for-arch.
So lets wait another minute please...
K, I pushed a new version of rocket:module to github.
Should I see the process initiated in the "Queueing Publish" box of the home page?
In principle yes...
Let me check!
Everything seem's fine on the autopublish.meteor.com side, but it got only the first trigger to test the hook you created...
No further triggers after then!
Could you please check at the bottom of this page how many 'Recent Deliveries` you see?
(I have no access to the page, obviously...)
...also, I'd like to make a recording of the screen while you're packages wil be being published...
Could you please let me know when you're making a new release again?
(edit: or you could do the screen recording yourself ;-) )
Btw, the settings for the hook should lool like this picture
Aha, tags wasn't selected. I deleted a tag and re-pushed it, now I see a new payload sent.
Cool, it showed up in the site. It errored. Getting closer. :D
Oh, let me try the newer version.
yeah, the log says:
error: No compatible binary build found for this package. Contact the package author and ask them to publish it for your platform.
But it should have scheduled five publishes... :(
Oh, wait.
You said you're using tags and not releases?
Yeah
mmm, but I can see two new releases here
Hmmm, I think GitHub makes those automatically based on the tags I've pushed.
I think it recognizes vX.X.X tags.
yep, it was a tag hook!
I have to add another bit of code to schedule accordingly also for tags...
...but: why is meteor publish failing?
Oh, hmmm, let me try it out here and see.
Oops, I was testing some code locally, but it isn't meant to run during publish. doh 😆 Let me fix and try that again.
It should be ready also for tags now!
at the next new tag, you should see five different publishing sheduled:
meteor publishfirstmeteor publish-for-archfour times later on
Okay, giving it a go!
Hehe. Perhaps the binary ones can be labeled like "rocket:module (os.linux.x86_64)", etc.
yep, that would be an improovement ;-)
I'm now curious to see what happened...
Build machines seem to be correctly taken and connected to, btw
error: No compatible binary build found for this package. Contact the package
author and ask them to publish it for your platform.
I wonder what that means. Hmmmmm.
😮 One succeeded! 😄
Did you ever get something like it locally?
...could it be something related to using a different user?
What I do now is:
- get a build machine
- login
meteorpublishwithmeteor login - git clone
meteor publishormeteor publish-for-arch
Which architecture what that for? I think I might know what's happening. Maybe while building for certain arch, a dependency for rocket:module can't be found in that arch. I might have to use a different tool!
Oh!!!! Its rocket:webpack. 😆
Now I can add rocket:webpack to autopublish.meteor.com. 😄
funny enough ;-)
I'll approve it and mark it as binary asap!
Would've been great if the error mentioned "rocket:webpack". Are you able to see if it does?
Everything's ready for rocket:webpacket!
...the log we can see on the browser is all I'm able to retrieve at the moment
mmm, actually this is the last part of the log string:
\\\r=> Errors while initializing project:\r Selecting package versions \\\rWhile checking for rocket:webpack@1.9.10_1:\nerror: No compatible binary build found for this package. Contact the package\nauthor and ask them to publish it for your platform.\r Selecting package versions \\
I might have some problem with \rs
I spoke too early!
If you got to the right end of the log textarea, you can see it!
What would you suggert to show the log in a more intelligible way??? :(
Hmmm, I didn't realize the text didn't wrap. If it wrapped I would've seen the error. I suppose preventing the text from scrolling to the side would be great (like happens in terminals)!
First one done!
...I'm adding the detail about the architecture for the items being published.
If you could wait a bit before making a new tag for rocket:module we should get a really good video ;-)
This is sooo awesome!!! wooooo!!! 👍
...but one failed ;-)
Ooops, "version already exists". 😆 haha
Will try again.
No, that's my fault actually!
It seems it's running meteor publish everytime and not meteor publish-for-arch!!!
I've changed a bit the selection of the publish command and I'm going to manually retrigger your tags.
I'll see if the first one succeeds...
Ok, we're getting there...
See this log
It seems you don't need a copy of the code when you run meteor publish-for-arch and you also have to specify packagename@version
...I'm sorry if you already told me and I didn't pick it up.
I'll have to change strategy a bit now...
It seems you don't need a copy of the code when you run meteor publish-for-arch and you also have to specify packagename@version
Yep! It will use the code submitted during the original meteor publish command, which only needs to run once. (:
Might it be helpful if the successful ones (green) can also be clicked to show the log (just no popup)?
Let me know when to try the next version. :)
Deployed!
Could you be so kind to release a new version of rocket:webpack?
Finger crossed! :-)
hehe :)
Is it doing one task now instead of 5?
If this one succeeds, the others will be scheduled later on...
sweeeet!
I have to admin that coding without having the possibility to test it locally might be difficult sometimes...
But if I got it right at first shot, I'll go to bed really happy :-)
hehe yeah!! Exactly what I thought about publishing to Atmosphere. The only way to test some scenarios is to actually publish things, which means we might publish junk versions.
actually, atmosphere is just a show off of the packages DB hosted by MDG.
But you're right, that's the truth.
I somewhere asked for a meteor publish --dry-run somewhere in the past, and a few people agreed that would make sense to have something to test your publish before actually publish.
...we're still at the same point tough!
I'm sorry man!
this time I run ~/.meteor/meteor publish-for-arch rocket:webpack@1.9. 10_3
(there's a \n in between 1.9. and 10_3...)
...this f....n' log full of \rs and \ns!!!! Grrrrrrrr.....
Let me improove a bit the parsing of the successfully published version :(
Ooof, so many \ Building package rocket:webpack animations. hehe.
Yeah, it's a pain...
I'd like to find out a good regexp to get rid of all that noise....
I once tried with this function but the result seemed to be missing something... :(
I'm lost!
The version retrieved from the successful publish seems to be correct: 1.9.10_3
and the command run later on seems to be correct too: ~/.meteor/meteor publish-for-arch rocket:webpack@1.9.10_3
But if you look at the log reported on the browser you see: ~/.meteor/meteor publish-for-arch rocket:webpack@1.9. 10_3 and, whatmore, if you copy/paste it you see a new line in the middle :-(
I saw that. Strange!
Is it ~/.meteor/meteor publish-for-arch rocket:webpack@1.9.?
mmm, perhaps it's just a problem with the log retrieval:
/.meteor/meteor whoami\nmeteorpublish\nrm -rf autopublish\n/.meteor/meteor publish-for-arch rocket:webpack@1.9. \r10_3\r Updating package catalog |\r Updating package catalog
Do you have any idea about why it could be failing?
The only meaningful part seems to be error: Cannot override existing build
Ironically, I posted that issue. x)
...I see :)
So what?
Was it published or not?!
...should we try publishing rocket:module then?
I've read it better. So it seems it all depends on which architecture you choose for the first publish...
Am I correct?
In fact there's no trace within the log of the first successful publish operation of this warning!
...do you think we should add a field to specify where to execute the first `meteor publish'?
It doesn't matter where we run meteor publish, since that just uploads the source (JavaScript runs everywhere). What @glasser is saying is that the binary build was canceled (although it threw an error) and it should be published as platform-agnostic, but this doesn't seem to be the case because rocket:module is complaining it can't find certain platform builds.
Let me give rocket:module another shot.
What do you think about changing "Version" to "v" so long versions don't push the time-ago box down?
vs
....mmm I understand it differently:
So when you build this package on a Mac, you get fsevents and Meteor detects that there is binary code here and publishes it as a Mac-specific package.
When you build it on other platforms, fsevents fails to install, but that's OK since it's an optional dependency. So it goes and publishes it as a platform-agnostic package.
This means to me that if you run meteor publish for the first time on MAC, the presence of fsevents make meteor think it's a binary packages and publishes it as platform specific. Which I guess it means you should have no problems when you publish it on a different machine later on...
If, on the other side, you publish on linux first, no binary dependency is detected and hence the package is published as platform agnostic for good!
Does this make any sense?