Command to view the status of a server (beamlog)

[stecman]

We need an easy way to find out what code is on any given server and where that code is in the repository now. Beam already saves information on servers about the last beamed commit, but there's currently no way to retrieve or parse this information using beam. The solution to get this information as is would be:

$ ssh example.com cat path/to/webroot/.beamlog
Deployer: stevie
Ref: remotes/origin/master
commit c4bbafdc440d538ffa669f9e873ff9708e074b7e
Author: Dr. Stevie Mayhew <[email protected]>
Date:   Thu Sep 5 13:00:46 2013 +1200

    Enhanced comments with memes

$ git branch -a --contains c4bbafdc4
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Solution

What beam needs is some sort of status command to take full advantage of the .beamlog file and the things it already knows (eg. exactly where your code is). Said command might work something like this:

$ beam status s1
Deployer: stevie
Ref: remotes/origin/master
commit c4bbafdc440d538ffa669f9e873ff9708e074b7e
Author: Dr. Stevie Mayhew <[email protected]>
Date:   Thu Sep 5 13:00:46 2013 +1200

   Rewrote all business logic in BASH

This commit is appears in:
    master
    remotes/origin/master

[camspiers]

1. Do you think it would be worth changing the format of the beam log file? I think I remember part of the original motivation for the current format was readability, but if we are going to have a command to read the log it might be better to write it in json.
2. I propose there should be a beam status command that gives the status of all servers in the server list.
3. We also need to ensure that when using the working copy flag a log is still written. What this will contain I don't know. Perhaps it should contain information about the current head, but also something that signifies the fact that the deployment was a working copy deployment.

[pieterv]

beam status [server-name] sounds really good!

If its not to hard it might be useful to show if the current commit is not the latest commit for that branch. I imagine that would be useful to see if staging is out of sync with the feature/ release branch.

[shane-nzer]

These are all great suggestions and Cam's point about working copy deployments needing a .beamlog file as well is spot on.

The only other consideration I can think of is a bit of forward thinking around how the server locking might work. Would this all be tied into the same .beamlog file. Perhaps it's a separate file (.beamlock) that called via beam lock s1.