search

vmware-archive / projectmonitor

Big Visible Chart CI aggregator
http://ci.pivotallabs.com
BSD 2-Clause "Simplified" License
428 stars 120 forks source link

CircleCI polling no longer works #81

Closed micahyoung closed 8 years ago

micahyoung commented 9 years ago

For legacy reasons, our project was configured to use CircleCI polling instead of webhooks. Our builds have been silently failing for a few weeks and when we looked into it, it seems this commit likely introduced the regression as it changes the CircleCI format to depend only on the webhooks-style:

https://github.com/pivotal/projectmonitor/commit/ed3283246ece4cf4ac7494012003a5c996c00288

Here is our stacktrace from /projects/PROJECT_ID/payload_log_entries:

The String into Integer is because the result from https://circleci.com/api/v1/project/USERNAME/PROJECT returns an array of hashes, not a hash [{}]

no implicit conversion of String into Integer
/home/vcap/app/lib/payload.rb:106:in `handle_processing_exception'
/home/vcap/app/lib/payload/circle_ci_payload.rb:15:in `rescue in convert_content!'
/home/vcap/app/lib/payload/circle_ci_payload.rb:12:in `convert_content!'
/home/vcap/app/lib/payload.rb:95:in `convert_build_content!'
/home/vcap/app/lib/payload.rb:41:in `build_status_content='
/home/vcap/app/lib/project_workload_handler.rb:35:in `update_ci_status'
/home/vcap/app/lib/project_workload_handler.rb:18:in `workload_complete'
/home/vcap/app/lib/poller_workload.rb:33:in `store'
/home/vcap/app/lib/project_poller.rb:109:in `block in add_workload_handlers'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/em/deferrable.rb:151:in `call'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/em/deferrable.rb:151:in `set_deferred_status'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/em/deferrable.rb:191:in `succeed'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/client.rb:114:in `unbind'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/client.rb:71:in `on_request_complete'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/http_connection.rb:129:in `block in post_init'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/http_connection.rb:144:in `call'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/http_connection.rb:144:in `<<'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/http_connection.rb:144:in `receive_data'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/em-http-request-1.1.2/lib/em-http/http_connection.rb:23:in `receive_data'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
/home/vcap/app/lib/project_poller.rb:28:in `run'
/home/vcap/app/lib/tasks/project_monitor.rake:4:in `block (2 levels) in <top (required)>'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:240:in `call'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:240:in `block in execute'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:235:in `each'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:235:in `execute'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/home/vcap/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/task.rb:165:in `invoke'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:150:in `invoke_task'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `each'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:106:in `block in top_level'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:115:in `run_with_threads'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:100:in `top_level'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:78:in `block in run'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:176:in `standard_exception_handling'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/lib/rake/application.rb:75:in `run'
/home/vcap/app/vendor/bundle/ruby/2.0.0/gems/rake-10.3.2/bin/rake:33:in `<top (required)>'
/home/vcap/app/vendor/bundle/ruby/2.0.0/bin/rake:23:in `load'
/home/vcap/app/vendor/bundle/ruby/2.0.0/bin/rake:23:in `<main>'
arjunsharma commented 8 years ago

It appears that the configuration of the CircleCI endpoint is incorrect. I ended up configuring the project to use webhooks (which appears to be working), but it would be nice for the polling to work.

It seems that Project Monitor is attempting to use /api/v1/projects/<PROJECT NAME>.json?api_key=<API KEY>

It actually needs to use /api/v1/project/<ORGANIZATION>/<PROJECT NAME>?circle-token=<API KEY>

This means that it also needs to collect "organization", and no longer needs to collect "username".

I might try and make a pull request for this if I can.