Giter Site home page Giter Site logo

erlang-github's Introduction

erlang-github

build

Github API v3 client for Erlang

Usage

egithub is implemented as an Erlang application. This means that in order to use it, you need to add it to your application's .app file or start it with:

application:ensure_all_started(egithub).

Once it has started you can start using any of the API calls.

Credentials

The GitHub's API offers very few endpoints that don't require any credentials and a lot that do. For providing credentials you have two options: basic authentication or OAuth. In both cases, you can just call a function from the egithub module to obtain Credentials, that you can later provide to the functions that require it.

Said functions are:

For example to get the information of the logged in user you can do the following:

Cred = egithub:basic_auth("username", "password"),
{ok, UserInfo} = egithub:user(Cred).

Webhooks

This library provides the basic functionality over which you can implement your own GitHub webhook service. The webhook events that are currently supported are only ping and pull_request. These two allow you to process the contents in a PR, write comments to it or add a PR review.

To accomplish this you need to implement the egithub_webhook behavior, which requires a single handle_pull_request/3 callback. This function receives the GitHub's credentials the PR data and the associated files.

By default, this library uses the GitHub's PR reviews feature. So, once your handle_pull_request/3 implementation is done processing the PR it will have to return the tuple {ok, pr_review()}, where pr_review() is a map with information regarding the Review (e.g. commit_id, body, event, and comments).

In case you want to use individual comments in your PR, you will have to set the review_style parameter within your application's config file to individual_comments, i.e:

{egithub, [{review_style, individual_comments}]},

And then, your handle_pull_request/3 will have to return the tuple {ok, [message()]}, where message() is a map with information regarding the comment (e.g. commit_id, path, etc).

Both, pr_review/0 and message/0 types are documented within the egithub_webhook module.

To start the whole webhook flow once you receive the request from GitHub on your endpoint you can call either egithub_webhook:event/3 or egithub_webhook:event/6. The function with arity 3 will just create the comments returned by your implementation. The second function will also make calls to the Statuses API and will report on the current status of the webhook.

GitHub's Rate Limits

If you use the GitHub API to create a lot of entities in a short interval, at a certain point you will hit a limit on the rate of requests you can do. This is sort of documented in the API's documentation, although there are no specifics on the amount of requests permitted or the interval considered.

To work around this limitation, egithub has a built-in detection mechanism that handles the case where an API call returns 403 after doing a valid requests. The request is queued and retried after a certain amount of time, based on a fibonacci backoff time series.

By default all API requests are done without this feature, which means you will get a 403 if you start doing a lot of requests one after the other. If you want to use this feature you need to provide the value queue for the option post_method. All functions in the egithub module that accept an Options argument, accept this option.

For example, if you wanted to create a large number of comments on an issue, you could use the egithub:issue_comment/5 like this:

Cred = egithub:basic_auth("username", "password"),
Repo = "username/reponame",
Issue = 1,
Comment = <<"Hello">>,
Options = #{post_method => queue},
egithub:issue_comment(Cred, Repo, Issue, Comment, Options).

This would create a comment with the text Hello for the issue username/repo#1.

API Documentation

There is an automatically generated API documentation page here.

Example

For an example on how to use this library you can check out this little Erlang application used to pull a JSON with all of Inaka's repositories in GitHub.

There is also a lot of code that calls the functions in egithub in the module egithub_webhook.

Contact Us

If you find any bugs or have a problem while using this library, please open an issue in this repo (or a pull request :)).

And you can check all of our open-source projects at inaka.github.io

erlang-github's People

Contributors

cabol avatar elbrujohalcon avatar euen avatar f3c0 avatar ferigis avatar guilleiguaran avatar harenson avatar hernanrivasacosta avatar igaray avatar jfacorro avatar paulo-ferraz-oliveira avatar samwar avatar spike886 avatar tgrk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

erlang-github's Issues

Looks like the project doesn't compile on Linux

@gadgetci reported…

2016-01-04 21:15:33.890 [info] <0.32528.95>@gadget_utils:run_command:113 make[2]: Entering directory `/tmp/gadget/inaka/erlang-github/0001451-0942105-0402250/deps/barrel_jiffy/c_src'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/gadget/inaka/erlang-github/0001451-0942105-0402250/deps/barrel_jiffy/c_src'
make -f c_src/Makefile.erlang.mk

2016-01-04 21:15:33.893 [info] <0.32528.95>@gadget_utils:run_command:113 make[2]: Entering directory `/tmp/gadget/inaka/erlang-github/0001451-0942105-0402250/deps/barrel_jiffy'
cc -o priv/barrel_jiffy_drv.so c_src/decoder.o c_src/encoder.o c_src/jiffy.o c_src/utf8.o c_src/util.o  -L /usr/local/lib/erlang/lib/erl_interface-3.7.20/lib -lerl_interface -lei   -shared

2016-01-04 21:15:33.902 [info] <0.32528.95>@gadget_utils:run_command:113 c_src/decoder.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make[2]: *** [priv/barrel_jiffy_drv.so] Error 1
make[2]: Leaving directory `/tmp/gadget/inaka/erlang-github/0001451-0942105-0402250/deps/barrel_jiffy'
make[1]: *** [pre-app] Error 2
make[1]: Leaving directory `/tmp/gadget/inaka/erlang-github/0001451-0942105-0402250/deps/barrel_jiffy'
make: *** [deps] Error 2

Hex.pm Package

Make sure the repo is rebar3-compatible and its deps are also hex.pm packages, then publish it on hex.pm using inaka's hex.pm account.

Simplify the expected return on egithub_webhook

Instead of requesting the callback module to find out the commit_id and the position let the module just return filename, line_number and text and do the rest of the processing inside egithub_webhook (use the current implementation in elvis_webhook as a reference).

Avoid needing to call jsx:decode/1 more than once per request.

egithub_webhook:request() should be opaque and have this spec: #{headers => map(), body => map() | binary()}.

Use a function to get the body which always returns a map and if the body in the request is a binary, parses it and returns the new request. Similar to what cowboy does.

Tests are not running

{"could not start kernel pid",application_controller,"error in config file "rel/test.config" (none): configuration file not found"}

Fulfill the open-source checklist

General Items

  • It has a github repo
  • It has a proper LICENSE file
  • It's hooked to a hipchat room
  • It's has a clear and useful README.md
  • It's documented (with examples)
  • It's tested

Exhibition

  • There is a blog post about it
  • It's shared on social networks
  • It's shared on reddit
  • It's shared on hacker news with a title like Show HN: description
  • It has a landing page built in github pages

For Libraries

  • It provides a sample application
  • Examples of use are documented in the README or linked from there

For Erlang Projects

  • It's checked with Elvis

Replace shotgun with hackney library

We need to replace shotgun for avoid dependencies conflicts because depends os cowlib 1.3.0 and egithub library depends of cowboy < 1.x que requires cowlib 1.0.1

Requirements

I am no longer able to build this project (with good old rebar). I just updated my fork from upstream and things are broken so I can't send a PR . It looks like one needs to have hex or/and rebar3 installed on his machine now. It might be a good idea to specify that in docs as a requirement.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.