Failed Publish Operations
splendido opened this issue · comments
Failed publish requests received on autopublish.meteor.com will be reported here.
Please investigate and report back...
After a publish operation is solved, please delete all related messages to keep this track clear!
All failures in this same issue?
Would it be possible to @-mention the user?
Yep, the mention is possible, and useful for sure...
What I get for free is the user who pushed the new release, but might not be the user to warn if we keep separate wrapper repos...
All notification under the same issue might reduce the pain to get 10-20 new issues on failure bursts (see the case for semantic-ui...)
I'm thinking maybe pushing emails to the maintainers of the packages is better then this thread?
@zimme, not all maintainers would be willing to receive annoying emails (see official integrations of 3rd party libraries for which we asked the upstream maintainers to register their own meteor user...)
But I agree that we should have some more advanced configuration options to let maintainers choose about this.
I thought about this thread because I supposed most of the errors could have been due to problems into the autopublish code, so basically I wanted to be warned when something went wrong...
And this prooved to be effective for the past meteor updates for which I had to manually update the meteor version on my build machine ;-)
What I could add for free (if I found the time...) is a mention to the author on this very same thread (as @dandv already suggested...)
Publish for package packaging:autopublish-test failed, please revise!
Publish for package zimme:iron-router-active failed, please revise!
@splendido, the publication actually went through, zimme:active-route@2.0.0-alpha.3 got published fine.
The log seems interrupted...
I'd say there' some problem with the code used to get the ssh connection and run commands :(
I'll have to look it better: I already had the feeling it crashed other times...
but wasn't it zimme:iron-router-active?
actually the log seems complete:
Publishing package build for zimme:ac... |\r Publishing package build for zimme:ac... |\r Publishing package build for zimme:ac... |\rPublished zimme:active-route@2.0.0-alpha.3.\r Publishing package build for zimme:ac... |\r Updating package catalog |\r Updating package catalog /\r Updating package catalog /\r Updating package catalog /\r Updating package catalog /\r Updating package catalog /\r Updating package catalog -\r Updating package catalog -\r Updating package catalog -\r Updating package catalog -\r Updating package catalog -\r Updating package catalog \\\r Updating package catalog \\\r Updating package catalog \\\r Updating package catalog \\\r Updating package catalog \\\r Updating package catalog |\r Updating package catalog |\r Updating package catalog
and there's a Published zimme:active-route@2.0.0-alpha.3 well before the end...
The thing is I'm using this regexp to verify successful publish and your package name is not aligned with the one on the subscription which is still zimme:iron-router-active
Unfortunately we're still not able to pick up a particular branch of a repository :(
Yeah, I'll rename the Github repo once 2.0.0 is stable then I won't see these errors anymore I guess.
But this is something to think about supporting. Mike with his mocha packages he publishes mocha-web from one branch and mocha-packages from another branch and if there's one user doing this, there might be others =)
is a git tag branch agnostic?
a git tag tracks a specific commit, it's a bit like a branch. But it shouldn't care about which branch it was tagged in. a tag should just represent a specific commit in the code base
so could/should we update the package name in the db reading it from the latest tag checked out before publish?
...or simply read the package name being published from package.js just before running meteor publish?
This could be a way to overcome the above error...
...obviously won't fit the case for developers using different branches for different packages ;-)
Reading from package.js from the checked out code sounds like a plan, that way the name will always be correct, even if I work from a separate branch and create a tag from there, which I need to do for autopublish to "trigger"
I just noticed autopublish is failing for our packages as of a few days ago
https://autopublish.meteor.com/log/tf22miRa42aRNqLhB
meteor --version
Meteor 1.1.0.2
meteor login
/
/
[1G[0JUsername: [11Gmeteorpublish
Password:
-
Login failed.
-
meteor whoami
Not logged in. 'meteor login' to log in.@splendido Any idea what's the issue?
@jlukic as you already noticed, the bot user is no more able to log in.
We've already understood what the problem is and we're in touch with MDG to solve the problem.
We'll let you know when everything will be back to normal.
I'm sorry for this.
No prob. Just ping me when its back up
I hope I'll have some answer in a couple of days...
Then we might think to change bot user and probably also the domain to simething like aurora.meteor.com, likely...
Hey guys,
publishing operations are catching up all failed requests since 7/7.
we're now using a new bot user called publishbot which is the one you have to add to your organization or as a maintainer of your packages to be able to get them published via autopublish.meteor.com.
Please see the updated how it works page with the new instructions...