search

MeteorPackaging / grunt-gulp-meteor

Gruntfile and Gulp file integration for Meteor
MIT License
6 stars 1 forks source link

Travis integration #3

Open dandv opened 9 years ago

dandv commented 9 years ago

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-- commented 9 years ago

:clap: Beautiful.

splendido commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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