Add git to the package publish workflow

[raix]

So I'm starting converting some of my packages, one thing I would really like is a param for adding a version tag to my git repo. I know that not all use github, but again alot do and this would help keep track of versions - optionally of course.

eg.:
My current workflow:

1. Make all changes and push to github
2. Bump version and push
3. meteor publish
4. g tag -a v0.0.1 -m 'Version 0.0.1'
5. g push origin v0.0.1

What I'd really like:

1. make all changes and push to github
2. meteor publish -bt

The last will bump version if no issues, tag, and publish the package - bumping patch pr. default, adding "m" for minor or "M" for major version bump.

Well, just my two cent

Kind regards Morten

[splendido]

👍
I also had to invent a (horrible) bash script to be able to bump, push, publish all the useraccounts suite at once.
See this file
having this automated by meteor will be much much better! :-)

[dandv]

👍

[splendido]

as another addition I'd say having something like meteor publish --simulate could be useful, especially for scripts used to publish many packages in a row.

It happened to me once that a publish inside a for loop failed (my fault!) and to recover it I had to spent a lot of time hacking the script to go again through the whole process ignoring whatever was successful at the first run.

The idea could be to organize scripts to backing up the current status, do all required changes, simulate all publish actions and only in case they were all successful actually run all publish commands. In case something fails during simulation restore the previous state.

Let me know if you think this is as OT, in which case we could open a separate issue here on directly on the official Meteor repo.

[raix]

Maybe have an option that makes sure all tests pass before publishing - tinytest/velocity?

[splendido]

actually it wasn't a problem with the package code, but with the package.js file which was badly updated by the same script I was using.

I think might be also helpful to test automated publish tasks to be used for external libraries (see Official Meteor integration discussion), while you play with Grunt/Gulp files, etc.

If you think there's no point about this, lets close here, no worries! ;-)

[dandv]

meteor publish --dryrun would be great in validating a number of things:

• namespace availability
• permission to publish (you may need to meteor login as a different user)
• valid package name (<100 chars, no illegal characters)

[splendido]

That's exactly it!

After tou get you're tests running ok, you might want to check also all the publish you're going to fire as another sanity check before actually start the real publishing process.

[awatson1978]

Agreed on the --dryrun or --simulate command. Not sure how that would look like in practice, but there are a few moments when a package first gets created that are prone to going awry and leaving an abandoned package.

As for the auto-pupblish script... the atom package manager has a similar system to what Morten is describing. It works well... except for when it doesn't. When things don't work, it persistently pushes broken packages to the repos and bumps version numbers. It's not uncommon to find packages with version numbers like 0.65.2 or 12.8.16 and so forth.

So, thinking it through, I like the -b and -t tags for bump and tag, respectively. It's a good balance. If you don't need the bump or tag, then you can still use vanilla publish.

[raix]

I did build https://github.com/raix/Meteor-mrtbulkrelease for the cfs project - theres alot of packages so it helps keep track of changes/bumping/publishing in bulk... I havent converted it into the new package system - but I have to, otherwise its a nightmare to maintain cfs.