Use CodeShip to publish Meteor Package on Atmosphere

If release early, release often (RERO) is your thing you’ll quickly notice wasting many hours to this release part. I intend to show you how part of this work can be taken away and make your life easier.

What’s CodeShip?

It’s SaaS providing Continuous Delivery service — it makes deployments of virtually any software extremely easy (once properly set up).

You are given quite decent virtual machine (1 build one at a time for free) where you can run unit tests, e2e tests and other code.

Start a new project and connect GitHub or Bitbucket repository.

Publishing Meteor Package

As an author of meteor package you probably know this workflow: make changes to the code, run tests, push changes, create/merge branch, run tests again, publish the package. Last two steps can be done for you.

Installing Meteor on CodeShip

Running standard Meteor install script (one from Meteor Docs) requires interactive sudo. This solution I borrowed from friends at cloudwith.me, just put it to CodeShip test setup commands:

$ curl -o meteor_install_script.sh https://install.meteor.com?release=1.4.1.1
$ chmod +x meteor_install_script.sh
$ sed -i “s/type sudo >\/dev\/null 2>&1/\ false /g” meteor_install_script.sh
$ ./meteor_install_script.sh
$ export PATH=$PATH:~/.meteor/

This one installs Meteor with desired version and, provided is run from $HOME directory, it makes meteor command available everywhere.

Non-interactive Meteor Login

Meteor Docs aren’t really saying much about it. They say something about storing tokens in a file and giving a path to it in METEOR_SESSION_FILE environment variable. It’s actually quite easy, you just have to do this simple steps on your local machine:

  1. Delete .meteorsession from you home dir ( rm ~/.meteorsession )
  2. Publish your package at least once (meteor publish in package folder)
  3. Store .meteorsession file created in your home directory (you may show its contents with cat ~/.meteorsession ) somewhere accessible from the Internet — private Gist is probably good idea, just make sure you’re downloading RAW version later.

Once you have that file you may download it on CodeShip’s VM and store it in a home directory.

$ wget https://gist.githubusercontent.com/jaaaco/some-path/your-meteor-session-file-url -O ~/.meteorsession

This command can be part of your setup or deployment script. Doesn’t matter where you put it. That way when you call meteor publish later it won’t ask for login and password.

Make sure you won’t call meteor logout with this exact .meteorsession file present — that would invalidate those tokens. It’s safe to remove ~/.meteorsession from your local machine now.

The only thing left is to publish your new package, you may call it on a specific branch (of you publish from stable or revision branches) — just make use of CodeShip deployment settings.

$ meteor publish
This is how deployment settings look like on CodeShip.com

That way every time you push something to master branch (in this case) and there will be a new version in package.js it will be published on Atmosphere.