gratipay / roobot Goto Github PK

https://www.google.com/alerts?t=1&q=gittip

It happens so rarely that it would be minimal noise, but some good news to talk about :)

https://github.com/jhubert/hubot-tweeter

Nifty little script we used at work, which allowed stuff like this:

roobot: tweet@gittip this is a test tweet

This could allow @whit537 to easily distribute control of the twitter account among a few trusted people, and it would bring the act of tweeting into the flow of chat.

We could also use it for the @gittip_status account during times when everyone is troubleshooting an issue that needs to be communicated (if we're still using this):

roobot: tweet@gittip_status NOOOOOO!! We're currently experiencing an outage! PANIC

Of course, it doesn't currently allow access control, so this is blocked on #12.

There's nothing privileged in roboot-test heroku app. Would be awesome if we could easily spin up a new heroku env, which would also copy all the important envvars from roobot-test.

We could steal the code from here:
https://github.com/heroku/heroku/blob/master/lib/heroku/command/fork.rb

patcon: roobot deploy gittip/roobot@a-feature-branch
roobot: Your feature branch is available here: https://roobot--a-feature-branch.herokuapp.com

Correlating events across systems and timezones is hard. Aiming to put everything in UTC for comparison between systems. But sometimes you still need to think in terms of native timezones (ie. "we were seeing that issue yesterday afternoon, but is that incident in librato the one I'm thinking?")

https://gist.github.com/patcon/9332299

or https://github.com/github/hubot-scripts/blob/master/src/scripts/time.coffee

We should package this script in its own npm package and host it.

Thinking we can do this without access control, in all honesty. This command would only deploy things to roobot-prod heroku app that are already on roobot-test. And things only get to roobot-test if they're tagged commits on "master", as that's all the travis is told to deploy.

Thinking this would pair nicely with a custom heroku buildpack that allowed us to use an envvar to set keybase.io users who must sign the tag in order for it to compile and deploy.

So basically, here's the pieces:

• set up travis to only deploy tagged commits on master to heroku
• custom heroku buildpack that expects something like this: HEROKU_BUILDPACK_SIGS=whit537,patcon,seanlinsley,<etc>
• enable heroku labs:enable user-env-compile (See: https://discussion.heroku.com/t/passing-environment-variables-to-slug-compiler/75)
• check the signed tag against keybase.io usernames from envvar, ensuring that it has been signed by an authorized user
• if everything looks good, deploy to roobot-test (ie. everything on roobot-test is cryptographically guaranteed trusted by us)
• use a hubot command to deploy a release from roobot-test to roobot-prod

EDIT: Apparently heroku labs:enable user-env-compile is enabled by default now:
http://stackoverflow.com/a/22909608/504018

Would be great to incorporate complete workflow:

• merging PR with big green button on github
• pull local changes from github, using grunt release to create signed tag
• pushing to heroku test env
• promote to production

Just send back a link with the query
https://botbot.me/freenode/gittip/search/?q=test+blah

Moved from hubot-archive/hubot-freshdesk-ticket-notifier#2

Currently, there are a few things we're duplicating in Gittip's notifier packages:

• various levels of setting notifier room:
  1. allowing the setting of one global room envvar for all notifiers (not yet possible to implement)
  2. setting room(s) via envvar per notifier (override)
  3. notification-level overriding via querystring param
• allowing default and customized route (not sure the value in this... but saw it done in gittip's pagerduty notifier)
• allowing custom mustache templating via envvar

test

If we're going to start trusting roobot to do important things, and if he lives on the public internet (which he does: https://user:[email protected]), then we need to know if someone is trying to bruteforce access through express framework's basic auth.

A failed attempt looks like this in the heroku logs:

2014-02-22T00:25:46.442907+00:00 heroku[router]: at=info method=GET path=/ host=roobot-prod.herokuapp.com request_id=3fcdfa4b-82a9-4780-b275-07058878b037 fwd="68.232.91.35" dyno=web.1 connect=7ms service=9ms status=401 bytes=214

Right now, we're using heroku's IRC deploy hook: gratipay/gratipay.com#2301

Using the http webhook and pointing it at a hubot route would make it so that the full payload was delivered, and the message would be set in one place, rather than in each apps envvars. This would also allow us to link to the github commit or the "compare" page for the diff between the last deploy, which isn't currently possible, as heroku msg templates don't have a mapping for the github repo :)

dsdfs

#13 made me realize that there are tons of scripts floating around that don't take authentication into consideration. Rather than try to force PR's into each external package, perhaps we could figure out something clever -- like having an envvar HUBOT_IRC_AUTH_REQUIRED where we set package/script names, with the intention that running commands from these packages/scripts requires a certain auth role. Or perhaps some sort of regex that requires broad sweeps of commands to got through auth.

Anyhow, something to think on for later.

It was noticed that roobot was essentially down, but I didn't receive a notification as his web process was stilling running and serving via the /ping route:
https://botbot.me/freenode/gittip/msg/11512011/

The logs looked fine, except suddenly there was no IRC activity.

It seems that hubot's process was simply not connecting to freenode. May have been related to heroku trying to build from a personal feature branch that had since been removed.

I've pushed fixes for that, and we'll see if they stay up. Might be worth adding some logging to the hubot-irc adapted to ensure that we're still connected to IRC...

https://github.com/myplanetdigital/hubot-gittip

Right now, I can adjust my take as a gittip team member, but I can't use gittip team funds to support projects/people who help make gittip happen. I suppose I could encourage them to join the gittip team and start upping their take, but that doesn't seem right.

Would it make sense to add the ability for anyone in the gittip chat room to control the giving of tips to other Gittip accounts (obviously not for giving to team members, as that's what the team feature is for).

(We don't yet have access control on hubot, and that issue is deeply rooted in how hubot works, but I think we could manage this without. So long as the tips coming out of the gittip account were only manipulable via the public chat room, and not via PM, then everything would be auditable. If some random person came in and adjusted their tip, /someone/ would notice, either from reading the scroll back or seeing it live. I think we could have this feature without needing access control, but we could always re-evaluate if there's an issue. And obviously we'd have a consensus on the level of discussion that would need to happen before initiating a weekly tip on behalf of the company :)

Would be great to be able to privately message roobot and get a space-separated list of people active in the past day. This would be helpful when @-mentioning people for events like standup

The diagram and explanation isn't up-to-date. It should explain that we deploy via travis

We might also want to add a roadmap section for #54

We can either submit a PR here:
https://github.com/github/hubot-scripts/blob/master/src/scripts/github-issue-link.coffee

Or, as per the new convention of github/hubot-scripts#1113, we could extract the script and generate a new one via this yeoman generator:
https://github.com/desmondmorris/generator-hubot-script

cc: @clone1018

Rationale

Adding people to G+ circles is important because circles are the main way that we can invite large groups of people to participate in a pre-arranged hangout-on-air at a future date. For example, we might start with a "team" circle for anyone who has expressed interest in the gittip project, but gradually move to a "coder" and "designer" and "artist" circle as we reach the need to invite certain segments of the contributor community to participate.

An invite to a pre-scheduled hangout-on-air will show up on a users google calendar, and allow them to RSVP from the gcal event. This will make is as simple as possible to remember the event and set aside time to participate, or perhaps simply listen in.

References

As of right now, G+ circles can be managed via API for personal G+ accounts:
https://developers.google.com/+/domains/api/circles

It seems that circles for G+ pages (where Gittip's circles fit), is by request only:
https://developers.google.com/+/api/pages-signup

I've sent a sign-up request.

In the meantime, I'll work on creating a script for managing personal circles. We can always share the personal circle and semi-regularly make sure everyone from that list is sync'ed with the corresponding Gittip page circle:
https://support.google.com/plus/answer/1684780?hl=en

Sample interaction

patcon>> roobot circle add [email protected]
roobot>> [email protected] has been added to the "code" circle
patcon>> roobot circle add [email protected] design music
roobot>> [email protected] has been added to the "design" and "music" circle
patcon>> roobot circle remove [email protected] code
roobot>> [email protected] has been removed from the "code" circle

cc: @whit537

This keeps happening :/

2014-02-19T18:58:51.226112+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2014-02-19T18:58:52.980963+00:00 heroku[web.1]: Process exited with status 0
2014-02-19T18:58:48.837723+00:00 heroku[web.1]: Idling
2014-02-19T18:58:48.840258+00:00 heroku[web.1]: State changed from up to down

Because the internet is serious business
https://github.com/mulvaney/hubot-meme

https://github.com/igui/cubot-hipchat/blob/master/scripts/calendar.coffee

Related:

• myplanetdigital/pantzbot#19
• myplanetdigital/pantzbot#18

Reticketed from #12

See nandub/hubot-irc#103

It would be nice to receive announcements in the channel when PR is switched to Review status.

We can set up a script so that not only can we manage incidents from chat and see who's on call, but can also have notification of incidents be dropped into chat as well.

https://github.com/erikh/hubot-pagerduty
https://github.com/github/hubot-scripts/blob/master/src/scripts/pagerduty.coffee

The idea is to make it dead simple for anyone to give anyone else (including themselves) write access to the calendar.

Sample usage

roobot calendar share [email protected]

Would just be kinda helpful

To detect problems early.

I <3 botbot, but sometimes he goes down and we lose important context. Would be nice to have a backup for those special conversations :)

(Obviously, helping make botbot better is the best alternative.)

Bonus points if we can turn logging on and off with a command, as that will likely keep us on a free heroku instance

https://github.com/jenrzzz/hubot-logger
https://github.com/adragomir/hubot-logger

Could use uptimerobot (free) to monitor an endpoint.

Could also use Loggly to monitor hubot logs using their heroku addon. (Also free)

Would be great to use this as an opportunity to start using a pagerduty workflow for gittip -- sending notifications when the hubot goes down. After all, if no one trusts when it will be available, they'll never want to depend on it :)

Psssst @m3matta :)

@michelp brought this up on IRC :)

There is currently no API for G+ pages, nor for creating a new hangout-on-air, although there is a "hack" to create a non-recorded hangout.

It was suggested to me by one of the hubot maintainers that at Github, they use mechanize to create other services that hubot talks to -- like a service-oriented architecture for hubot.

From the README:

The Mechanize library is used for automating interaction with websites. Mechanize automatically stores and sends cookies, follows redirects, and can follow links and submit forms. Form fields can be populated and submitted. Mechanize also keeps track of the sites that you have visited as a history.

Seems perhaps we could script the management of hangouts so that anyone looking to talk face-to-face could do so with a recorded copy.

This is pretty low priority, but I think the more face-time we get, the better :)

Rather than store the script in the hubot repo, would be great to just pull one of these:

curl https://raw.github.com/gittip/www.gittip.com/master/scripts/create_payday_droplet.sh | bash

That way, the logic stays with the codebase and people can easily submit pull requests and know it's there.

Blocked on #15

http://en.wikipedia.org/wiki/Myers_briggs

OK, this will be a pet project. I wanted to do this at my last job, but never got around to it. Myers-Briggs is a personality tool that allows you to fill out a questionnaire and determine the 4-letter "type" for your personality traits, with each letter-place corresponding to a scale with two ends -- ENLP, INLP, etc etc. I know people who swear by it, and go to great lengths to build maximally compatible teams by pairing personalities appropriately.

The thought is that, for those who care to evaluate themselves and provide their type, it might help us to understand how we might be clashing with others in approach and point-of-view, which could be particularly helpful since so much of our communication is via text, and it might be hard to understand compatibility compared to in-person interactions.

Here's how I imagine it might work:

• One command links to a questionnaire, so we're all using the same baseline.
• Another command allows each person to set their Myers-Briggs type.
• Another command allows you to check anyone else type.
• Another command allows you to see how compatible you might be with someone else's type:
  http://www.massmatch.com/MBTI-2.php

Yes, it's never going to be the full picture, but it might help us understand where to start in order to best work with one another :)

https://github.com/github/hubot-scripts/blob/master/src/scripts/github-pull-request-notifier.coffee

I think maybe they're tied to my account, or i misunderstood how ticket state worked when I created the command.

At the moment, I have roobot deploying with an API key from my personal account. It seems that the recommended way of operating is to give each app its own heroku account, to help isolate concerns.

At the very least, we should be generating the keys with a special dummy heroku account, yes?

This will be useful for that: https://github.com/ddollar/heroku-accounts

To Do

• create dummy heroku account (email? not sure if this is too heavy for [email protected], which goes to general freshdesk support)
• regenerate travis configs

I think this was a big oversight that made it a bad idea to trust hubot with passing along important messages. Fixed in PR.

lorenzhs/hubot-tell#11

testing

I don't know about you guys, but I do this a bunch of times a day when trying to cross-reference convos. Would be cool if we could do it via a private msg to roobot and get the link really easily without loading up a new tab. Would also work in the public channel, but I suppose that would be discouraged if it's not helping the convo somehow

See gratipay/gratipay.com#2094

Would be great if anyone with a certain role in hubot could do a restart.

As discussed in Hangout standup.

Final thought was that subject lines are too personal to drop into the public chat, but that we could create Dispatchr rules (a Freshdesk thing) to tag priority based on certain keywords, and include the priority in the chat notification.

Suggested events to notify on:
New ticket
Agent responded (?)
Customer replied
Closed

roobot>> [Freshdesk] #222 (★★★☆) - Ticket created. http://...
# Some replies and sets priority down to low as not actually urgent
roobot>> [Freshdesk] #222 (★☆☆☆) - Customer responded. http://...
# Agent responds and closes
roobot>> [Freshdesk] #222 (★☆☆☆) - Ticket closed. http://...

cc: @whit537 @pjf @bruceadams

EDIT: Most obviously for support@ tickets, to start with. vendors@ has some useful emails, but mostly noise

https://github.com/github/hubot-scripts/blob/master/src/scripts/github-search.coffee

Someone will frequently bring up an idea or issue, and often, someone who's been around longer will say "Yeah, I think we had an issue for that", then they'll go silent as they usually go and find it.

Would be great to bring this process into the conversation.

https://botbot.me/freenode/gittip/msg/12698505/

Just makes sense :)

Todo

• extract tell.coffee in npm package as per github/hubot-scripts#1113
• deprecate community tell.coffee script
• add ability to run hubot tell whit537,bruceadams a thing i want to tell them

cc: @pjf

https://github.com/github/hubot-scripts/blob/master/src/scripts/github-issue-link.coffee#L33

Likely need to extract that script into its own npm package, since the community scripts are no longer taking improvements

See: https://github.com/patcon/hubot-heroku-deploy-notifier/blob/master/src/heroku-deploy-notifier.coffee#L54-L68

This should be working for building-gittip-com: https://botbot.me/freenode/gittip/msg/13705769/

Should add some logging to see where things are going awry