bradleyfalzon / gopherci / 171
63%
master: 61%

LAST BUILD BRANCH: review-no-approve
DEFAULT BRANCH: master
Ran
Jobs 1
Files 13
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
171

push

travis-ci

bradleyfalzon 
GCPPubSub refactor to support new streaming client API

Google have recently made some breaking changes to their Pub/Sub
client API to support new high performance streaming methods.

https://groups.google.com/forum/#!topic/google-api-go-announce/aaqRDIQ3rvU/discussion
https://groups.google.com/forum/#!topic/google-api-go-announce/8pt6oetAdKc/discussion

The main change is the new methods don't easily support blocking
operations, nor one message at a time use cases. This is being
discussed: https://github.com/GoogleCloudPlatform/google-cloud-go/issues/566

This change attempts to use the new API but in a blocking method
indirectly discussed: https://github.com/GoogleCloudPlatform/google-cloud-go/issues/569

Since finishing and testing this method, which was successful, it
appears Google is discussing this use case further internally, so
this may not be the final solution, but gets us through for the moment.

If we're required to stop using the Pub/Sub client, and instead use
the APIv1 client, the issue does contain a gist of how it could work,
but it hasn't been tested in various failure modes, as it's a lower
level API - but I'm confident it just requires more testing and likely
no more changes.

Further, these changes did necessitate some refectoring on the internal
APIs, this was mostly opportunistic but made the changes simpler.

This refactors were essentially use a channel to push messages onto
the queue, previously this was an interface called Queuer. Also,
previously new jobs to be executed were sent on a channel, instead
each type of queuer should take a callback, and execute that callback
with the job as the only parameter.

A callback was chosen instead of another channel, as I wanted to ensure
only one message was consumed at a time, so the new APIs Receive method
has only one instance running, and calls the callback, blocking until
finished. When using a syncronous channel the Receive method became
asyncronous because it would unblock as ... (continued)

581 of 927 relevant lines covered (62.68%)

1.7 hits per line

Jobs
ID Job ID Ran Files Coverage
1 171.1 (GOOGLE_APPLICATION_CREDENTIALS=/tmp/gcloud-GopherCI-dev.json) 0
62.68
 Travis Job 171.1
Source Files on build 171
Detailed source file information is not available for this build.