Travis integration

[dandv]

Done - see the Hammer.js template.

Note that Meteor must be installed from .travis.yml as well as from package.json. Letting grunt-exec install it breaks randomly.

[PEM--]

👏 Beautiful.

[splendido]

I might be blind.... but I could find only testing features
Is it only for testing or have you managed to run meteor publish on TraviCI?

[dandv]

Moving here the idea from #2:

Idea: could we run meteor publish if there's a new version in package.json, from the Travis box? That would require setting Travis environment variables to a "meteorpublish" MD user/pass (I've just created one) and passing those to meteor login's password prompt. This botuser would be a security weakspot though, as it would have publish rights to all wrapper packages.

[splendido]

The only automation we could set in place I can think of now, is asking Travis to warn us every time a new tag/release is added on the repo.

See Running-commands-before-and-after-release

We could have the MD user you're referencing opening a new issue on a dedicated repo (Packages needing a new Release) on MeteorPackaging every time one of the official porting has a new release.

Then some of the devs part of the organization could run by hand the meteor publish and close the issue.

This would be needed only for those project for which their maintainers won't accept to install Meteor and have the meteor release task integrated into their grunt/gulp file...

Edit: The only automation I can think of now from my unexperienced positon ;-)
Edit 2: github api to open a new issue