Failed Publish Operations

[splendido]

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!

[dandv]

All failures in this same issue?

Would it be possible to @-mention the user?

[splendido]

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...)

[zimme]

I'm thinking maybe pushing emails to the maintainers of the packages is better then this thread?

[splendido]

@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...)

[tredondo]

Publish for package packaging:autopublish-test failed, please revise!

[tredondo]

Publish for package zimme:iron-router-active failed, please revise!

[zimme]

@splendido, the publication actually went through, zimme:active-route@2.0.0-alpha.3 got published fine.

[splendido]

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...

[splendido]

but wasn't it zimme:iron-router-active?

[splendido]

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 :(

[zimme]

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 =)

[splendido]

is a git tag branch agnostic?

[zimme]

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

[splendido]

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...