Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Apr 25, 2009
  1. @runpaint

    Limit number of repetitions for retryable requests

    runpaint authored
    If a RetryableAPIError exception is raised, we only repeat the request
    MAX_RETRIES number of times before raising an APIError. This guards against
    infinite loops, while still allowing most 403 errors to be worked around.
    As I explained in the commit message for
    6cae2e3, this logic is still pretty vague
    because GitHub hasn't documented their rate limiting policy yet.
  2. @runpaint

    Retry 403s and Net::HTTPBadResponse errors.

    runpaint authored
    My testing strongly suggests that when GitHub returns status code 403 the
    request can be retried. This may be how they implement rate limiting. So, if
    we get a 403 we simply repeat the request. We don't wait between requests
    because there is not yet any evidence that it would benefit us. Hopefully,
    once the rate limiting is documented, we can revisit this issue.
    We also retry on Net::HTTPBadResponse exceptions. These are typically raised
    when something between the client and the server clobbers the response, so
    repeating the request is the most sensible approach.
    We don't limit the number of retries which means this code could end up
    looping forever. I'm loath to specify some arbitrary limit, however, without
    documentation on what to expect. For example, in the case of 403 errors, my
    testing reveals that sometimes we succeed after retrying twice, and other
    times it may take nearly ten retries.
Commits on Apr 24, 2009
  1. @runpaint
Commits on Apr 23, 2009
  1. @runpaint

    Make .keys and .emails return Arrays.

    runpaint authored
    The .keys and .emails methods were returning HTTParty responses which were
    confusing to the caller, and contained an unnecessary level of depth. We now
    index the response with the appropriate hash key, thus returning its Array
  2. @runpaint

    Removing superfluous yield.

    runpaint authored
    The `submit` method yields to the block it's been passed, prints out a trace,
    then makes almost the same yield again. I assume that this is in error, and
    could have been caused by my previous merge.
  3. @runpaint

    Undo 3cb8fbd.

    runpaint authored
    Commit 3cb8fbd has been made obsolete by
    commit 67320c5. Now we're appending the
    credentials to GET requests, .keys and .emails can return to using the correct
    request type.
  4. @runpaint

    Add credentials to `default_params` for auth'd GET.

    runpaint authored
    We want the token and login to be sent for all authenticated queries. They
    were being sent for POST requests, but, seemingly, not for GETs, causing
    methods relying on the latter to fail. HTTParty's `default_params` method
    causes parameters so set to be sent on every request. We specify `login` and
    `token` as default parameters if the request is authenticated.
  5. @runpaint

    POST is required for /user/keys and /user/emails.

    runpaint authored
    The .keys and .emails methods returned a "not authenticated" error because
    they were fetched via GET and thus the credentials were not sent. Using POST
    fixes this bug.
Commits on Apr 22, 2009
  1. @runpaint

    Merge branch 'master' of git://

    runpaint authored
Commits on Apr 21, 2009
  1. @runpaint @fcoury

    Complain about status code before content type.

    runpaint authored fcoury committed
    GitHub currently returns 500 errors as HTML. When we encountered this, the
    error message referred to the content type rather than the status code. Now we
    check the status code first, so errors are more informative.
    Signed-off-by: Felipe Coury <>
  2. @runpaint

    Complain about status code before content type.

    runpaint authored
    GitHub currently returns 500 errors as HTML. When we encountered this, the
    error message referred to the content type rather than the status code. Now we
    check the status code first, so errors are more informative.
Commits on Apr 20, 2009
  1. @runpaint

    Add Base.validate_args, refactored error classes.

    runpaint authored
    Children of Base can now call self.validate_args with a hash containing
    arguments as keys and a corresponding specification symbol as the key. If any
    arguments are invalidated, an informative ArgumentError is raised.
  2. @runpaint

    Sanity check for response content type.

    runpaint authored
    The API should respond with data in the same format as we requested. If the
    Content-Type disagrees with what we expected, we raise an exception.
    This is currently broken for raw Git data as the API call returns the wrong
    content type. Reported as develop/
  3. @runpaint
  4. @runpaint

    Add .clone_url method to Repository objects.

    runpaint authored
    Repository objects have a .clone_url method which returns their public clone
  5. @runpaint

    Let find/find_all methods accept objects.

    runpaint authored
    Initial draft of letting the user-facing methods, find/find_all, mostly,
    accept an object corresponding to the argument type instead of a string.
  6. @runpaint

    Tweaked Repository.find_all's argument handling.

    runpaint authored
    Repository.find_all accepted an array of 'words', which it concatenated with
    '+'. It now also accepts a single space-separated String, or any combination
    of the two.
    This method is still buggy, however, in that the query is not URI escaped;
    it's simply interpolated as-is into the URI. Peculiarly, the API doesn't
    accept URI-escaped space-separated queries, e.g. 'ruby%20spec'. This is
    non-standard enough to put off escaping until I know exactly what the API
  7. @runpaint

    Tag.find accepts User a/o Repository object args.

    runpaint authored
    Tag.find(user,repo) assumed user and repo were Strings; now it does the right
    thing if one or both arguments are User or Repository objects, respectively.
  8. @runpaint
Commits on Apr 19, 2009
  1. @runpaint

    find/find_all join Array arg with '/'.

    runpaint authored
    A number of callers were joining their arguments with '/' before passing them
    to find/find_all. Now these methods automatically do this if passed an array.
    There's still duplicate code, but it's better than it was.
  2. @runpaint

    Initial implementation of the Object API.

    runpaint authored
    * The `tree/show/:user/:repo/:tree_sha` call returns an array of objects in
    the given tree. This is exposed by the FileObject class. The name is
    convoluted because Object is a reserved word. 'Tree' is awkward because
    although the argument describes a tree, the returned objects aren't trees...
    We should probably call this Tree, and have it return an array of FileObject
    * The `blob/show/:user/:repo/:tree_sha/:path` call is supported by
    Blob.find(user, repo, sha, path).
    * The `blob/show/:user/:repo/:sha` call returns raw Git data irrespective of
    caller's format preference. To handle this a get_raw method has been defined
    which simply requests a given path and returns the raw body without attempting
    to coerce it into a data structure. The right way to handle this is to format
    based on the Content-Type header in the response, but that is always set to
    text/html, so is useless. Blob.find(user, repo, sha) returns said raw data.
    * The .find method is now intelligent about arrays. If yaml[key] is an array,
    each element is assumed to be a hash constituting a new object. I still don't
    claim to understand all the magic of this module, so this enchantment may very
    well be unnecessary, but it enabled some hairy code to be factored out, so it
    stays for now.
    * The .find_all method now accepts a block, to which it passes the data it
    intends to construct a new object with. This is to allow callers to massage
    an arbitrary data structure into a simple hash. This is used for Tag.find
    because GitHub returns a single hash of tags, rather than one hash per tag.
    (Yes, I realise that this is a ridiculously long commit, and, yes, I have
    heard of cherry-pick...)
  3. @runpaint

    Improved handling of API errors.

    runpaint authored
    GitHub API errors aren't reported consistently yet. Sometimes they return
    reams of HTML and a non-200 status code, other times they return a 200 status
    code and an error message. We now handle both of these cases by raising an
    APIError with an appropriate message. This will need to be updated as the API
    standardises. When it does, we want to interpret 404s, for example, as the
    object not being found, and thus provide an informative error message.
  4. @runpaint

    Support for viewing a repository's tags.

    runpaint authored
    There's now a Tag class so you can ask for the tags of user's repo with
    Tag.find(user, repo). Plus, all repository objects respond to .tags, which
    returns an array of Tag objects. This isn't the pretties code but it works,
    and that's enough for now.
  5. @runpaint

    Raise APIError if GitHub returns bad status code.

    runpaint authored
    If can't handle the API request, either due to user error or server
    error, it returns an utterly useless chunk of HTML. This confuses the library,
    so we now raise an APIError if the status code is anything other than 200.
    Better error handling will have to wait until the API supports it.
  6. @runpaint

    Let Repository.find(user) show user's repositories

    runpaint authored
    Hacked Repository.find so if called with a single argument, assumes it to be a
    user name, and returns an array of Repository objects corresponding to the
    user's repositories.
    I don't completely understand this library's architecture, so it's likely my
    implementation is Wrong. ;-) Works for me, though.
Something went wrong with that request. Please try again.