flowdock / flowdock-api Goto Github PK

For automated environments (like my continuous deployment Jenkins setup) I don't have a git repo, so going through the repo directly to get list of changes between deploys is error-prone.
Now, as pointed before in capistrano/capistrano#757 I set previous_revision and current_revision variables back in Capistrano 3.
I might be able to work on a fix for this particular scenario on Capistrano 2, but I'm not really sure whether I'll have the time to do it.
In Capistrano 3, we should prefer to go through the aforementioned variables instead of the repo instance, as it might not exist at all. All the information should be retrieved from the remote and the current state of the local checkout on the deployment server as opposed to the local one.
Comments welcome.

We would like to announce deploys to every room (or to an enumerated list of rooms). This is pretty difficult with the current version. I see two obvious options:

1. add a Ruby API that looks like a multi-flow announcement, but really just makes multiple HTTP requests
2. add true multi-flow announcements to the Flowdock HTTP API (say, with a comma-separated list)

I'm happy to help with the former or with the Ruby part of the latter.

I've purposefully not set :branch in my Capfile, to be able to deploy the currently checked out branch. This causes notifications to fail, however, wth

    triggering after callbacks for `deploy'
  * 2013-10-15 10:47:00 executing `flowdock:notify_deploy_finished'
    triggering before callbacks for `flowdock:notify_deploy_finished'
  * 2013-10-15 10:47:00 executing `flowdock:set_flowdock_api'
Flowdock: error in sending notification to your flow: undefined local variable or method `branch' for #<Capistrano::Configuration::Namespaces::Namespace:0x007fcff24d2168>
  * 2013-10-15 10:47:00 executing `flowdock:save_deployed_branch'
  * executing "echo 'HEAD' > /path/to/myapp/current/BRANCH"

I think the process should be smart enough to git rev-parse --abbrev-ref HEAD if the branch has not been given.

Hey,

Last version of the gem (0.3.1) is 11 months old, do you plan to release a new version anytime soon ?

Thanks

cap deploy:restart


  * executing `deploy:restart'
    triggering before callbacks for `deploy:restart'
  * executing "touch ..cap/current/tmp/restart.txt"
....
    triggering after callbacks for `deploy:restart'
  * executing `flowdock:notify_deploy_finished'
    triggering before callbacks for `flowdock:notify_deploy_finished'
  * executing `flowdock:set_flowdock_api'
    triggering before callbacks for `flowdock:set_flowdock_api'

triggering before callbacks for `flowdock:set_flowdock_api'
...lobal/gems/capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:188:in `method_missing': undefined local variable or method `current_branch' for #<Capistrano::Configuration::Namespaces::Namespace:0x3c7ee00> (NameError)

Maybe at: https://github.com/flowdock/flowdock-api/blob/master/lib/flowdock/capistrano.rb#L62

I would use somthing related to "deploy:symlink"

Anyway, I'm not sure if server restart should be informed by default. But at least calling plain "cap deploy:restart" should work as before.

Otherwise, it works great. With usual deploy notifies are good.

Yeah, after last issue ( #4 ) this was quite obvious :)

So i'm not sure where it should be handled normally. But in generally I would want that flowdock would never create errors in my capistrano excecutements. Especially it should never stop my deploying scripts. If I break my production server, i want to be able to use the commants as excected, then I don't really care if flow gets notified or not, I'm in a hurry...

It should just pass and log some errors etc. In https://github.com/flowdock/flowdock-api/blob/master/lib/flowdock/capistrano.rb#L36 something like

unless defined?(current_branch)
   your code
else
   puts "Flowdock could not be informed, no branch set, debug or contact support"
end

Some trace:

    command finished in 738ms
    triggering after callbacks for `deploy:symlink'
  * executing `flowdock:notify_deploy_finished'
    triggering before callbacks for `flowdock:notify_deploy_finished'
  * executing `flowdock:set_flowdock_api'
    triggering before callbacks for `flowdock:set_flowdock_api'
/home/ohu/.rvm/gems/ree-1.8.7-2011.03/gems/capistrano-2.9.0/lib/capistrano/configuration/namespaces.rb:188:in `method_missing': undefined local variable or method `current_branch' for #<Capistrano::Configuration::Namespaces::Namespace:0x24fbe68> (NameError)

I think there is a problem in the capistrano file, line 19 (https://github.com/flowdock/flowdock-api/blob/master/lib/flowdock/capistrano.rb#L19 ):

set :rails_env, (!stage.nil?) ? stage : ENV['RAILS_ENV']

Because capistrano provides "variables" via method_missing, calling nil? on an undefined capistrano variable results in

 `method_missing': undefined local variable or method `stage'

see http://groups.google.com/group/capistrano/browse_thread/thread/57733d9ce4c43ad2

A solution would be using variables.include?(:stage) instead of stage.nil?

HI
I am using this in production app and sometimes it slows down the app, can there be option for HTTPParty via Flow clas to set timeout?

thanks

Hi - trying to get this to support proxy servers, as it's a requirement for my implementation. I'm not seeing an easy way to pass thru options to HTTParty, but i think on HTTParty side should be easy to add the necessary options for proxy support if needed.

I'm wondering if maybe a bit of refactor around HOW options are passed back to HTTParty - maybe a hash instead of just a bunch of KV pairs? Thoughts? Help? :)

Just wanted to post here, that I just created mina-flowdock, a small gem to add flowdock notifications when using mina for deployment.

Would it be worthwhile to add a note to the README?

It's very convenient to have a changelog when updating gems just to have an idea what could break. Thanks.

All the builds are apparently error-ing because of HTTParty failing to install in 1.8.7. Now, 1.8.7 saw end of life in July iirc, I don't know why you're still building against it.
In case you do need to do it, you need to either lockdown httparty to a version that ran in 1.8.7 or switch to a different http library (such as 1.8.7's Net::HTTP for example).

Full error message and log at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867649

GET /flows/:organization/:flow/users

contains users who where kicked from the organization.

For example: The user "MasterX" was kicked about 3 months ago.

GET /organizations/:organization/users

does not show him but the first call does.

Would be great to release v 0.5 to Rubygems! Thanks