jedcn / hipchat-hotline Goto Github PK

If you just run hipchat-hotline, you see something like this:

❯ hipchat-hotline
/opt/boxen/nodenv/versions/v0.10.31/lib/node_modules/hipchat-hotline/lib/hip-heuristic.js:63
      if (this.recipient().indexOf('@') > -1) {
                           ^
TypeError: Cannot call method 'indexOf' of undefined
    at Object.publicAPI.recipientType (/opt/boxen/nodenv/versions/v0.10.31/lib/node_modules/hipchat-hotline/lib/hip-heuristic.js:63:28)
    at sendMessage (/opt/boxen/nodenv/versions/v0.10.31/lib/node_modules/hipchat-hotline/lib/hipchat-hotline.js:28:16)
    at Object.hotline (/opt/boxen/nodenv/versions/v0.10.31/lib/node_modules/hipchat-hotline/lib/hipchat-hotline.js:37:3)

And instead you should see something like:

❯ hipchat-hotline

Usage: hipchat-hotline <recipient> <message>

Options
  When sending to either user or room:
    --message-format text | html
    --notify true | false
  When sending to room:
    --color green | red | gray | purple

Overview

Presently, your hip chat credentials need to be put into the environment as a variable named HIPCHAT_API_TOKEN. It would be easier if these could be stored in a file.

Approach 1: .env

When running hipchat-hotline, we could read a file named .env in the working directory and inject variables from that file into the environment and then run hipchat-hotline. This is dotenv.

Approach 2: recursively-searched-for-.envs or .hipchat-hotlinercs

A drawback of Approach 1 is that you'd always have to run hipchat-hotline from the same directory. Instead, it could work like rake and start looking "up" directories from the working directory to a file that is named .env or .hipchat-hotlinerc.

Approach 3: $HOME/.hipchat-hotlinerc

A drawback of Approach 2 is that you'd always have to run hipchat-hotline from a subdirectory of where this file was stored. That could work if you put the file at the root of your OS: /.env, but it'd fail sooner or later otherwise (say you put it in $HOME but then you ran hipchat-hotline from /tmp)

Instead, it could work by presuming a .env or a .hipchat-clientrc exists in a well known location, such as $HOME/.hipchat-hotlinerc.

Approach 4:

Some combination of all of these.

Regardless of which, my assumption is that the file would contain a line like:

HIPCHAT_API_TOKEN=XYZ

I've noticed several times with 0.1.0 that a message will be sent as the wrong color.

Meaning, I can run this command:

hipchat-hotline --color red SomeRoom "A Message"

And it'll be green instead of red. But.. if I wait 30 seconds an try again, it'll be red.

Same goes for html vs text:

hipchat-hotline [email protected] "A <b>message</b>"

And this should be sent as html (the word "message" should be in bold) but it comes in as text, and you see the bare <b>s.

However.. like is mentioned above.. if you wait 30 seconds and try again, it works.

Is this a problem with hipchat-hotline? The embedded hipchat client (hipchatter) or hipchat.com itself? I don't know.

This would be helpful for troubleshooting purposes:

❯ hipchat-hotline --version
v0.1.0

If you try to use hipchat-hotline and it encounters an error, then the exit code should be non-zero.

❯ hipchat-hotline @UserDoesNotExist Hi
Problem: Error: Target user @UserDoesNotExist is not a valid user
~ ❯ echo $?
0

That 0 should be a 1 to indicate that an error occured.

This helps with script/jenkins/whatever integration.