GNOME Bugzilla – Bug 741684
Add a GitHub provider
Last modified: 2021-07-05 10:59:07 UTC
I have written a goa backend for github. My need is to write a small sticky-notes type application to store all temporary test programs I write freequently. Instead of storing locally, the app should store it in gist.github.com choosing gist.github.com over other pastbin servies is to make sure I store it in my account permanently and share it with others (in irc or some other way) * First step is to enance GOA to work with Github * Second step is to write gjs class which will mirror github rest api (atleast for gists) * Final step is to write gjs frontend app to view/store programs and other notes in gists.
Created attachment 292940 [details] [review] patch for github backend
Created attachment 292941 [details] github icon files
Created attachment 293197 [details] [review] patch with github backend and javascript github api
I have added a simple github api now (currently only provides gists). It would be great if someone look at the patch and provide review.
Review of attachment 293197 [details] [review]: Thank you very much for the patch. We usually add a new online provider to gnome-online-accounts when a default / core GNOME application is going to make use of it, and any other application is free to use these accounts. Do you know of any core / default GNOME application which is going to use a GitHub account? Maybe gnome-builder? Otherwise, I would suggest that you handle the accounts directly in your application for the time being. That said, a few comments on your patch. ::: src/goabackend/goagithubprovider.c @@ +1,2 @@ +/* + * Copyright (C) 2014 Gnome Foundation. This is wrong. Unless you have formally assigned your copyright to GNOME Foundation, which I doubt is the case here, you own the copyright. @@ +60,3 @@ + return r; \ + } \ + }while(0) Please don't use these macros. Follow the same structure as in the other providers. @@ +209,3 @@ + RN(error, payload, NULL); + g_object_unref(apicall); + g_object_unref(apiconn); Please release all resources in one 'out' section at the end of the function. eg., see goagoogleprovider.c and goafacebookprovider.c. ::: src/js/github.js @@ +1,3 @@ +/* + * github.js - github api using goa-github-provider + */ gnome-online-accounts is not the place for a GitHub API wrapper. I would suggest creating a separate C library that wraps the API using GObject with GMainLoop integration, asynchronous methods, etc.. You can take a look at how libgdata and libzapojit does it for the Google and OneDrive APIs. Ideally, there would be an easy way to use a GOA GitHub account to authenticate using this library, but it would also be possible to use it with other 'account sources'. You can look at GDataAuthorizer and ZpjAuthorizer for examples.
(In reply to comment #5) > Do you know of any core / default GNOME application > which is going to use a GitHub account? Maybe gnome-builder? none of core/gnome apps have plans to use this. But, gnome-builder is a great idea, It will be great if gnome-builder have integration directly with github. I like to contribute to gnome-builder to implement this integration. I'm new to gnome-development and I don't know where to start. I want to be part of gnome development some way. >gnome-online-accounts is not the place for a GitHub API wrapper. I would > suggest creating a separate C library that wraps the API using GObject with > GMainLoop integration, asynchronous methods, etc.. You can take a look at how > libgdata and libzapojit does it for the Google and OneDrive APIs. Ideally, > there would be an easy way to use a GOA GitHub account to authenticate using > this library, but it would also be possible to use it with other 'account > sources'. You can look at GDataAuthorizer and ZpjAuthorizer for examples. the javascript class (github.js) provides what a GObject wrapper library can provide, but its limited to gjs. I would like to share my openion on writing GObject wrapper for webapis 1. Most of the web talks in json and I feel we are yet to come-up with a good solution to marshell between GObject-to-Json and vice-versa. (I know json-glib is capable of doing this, but either we need to parse node-by-node or we need to create GObject types for every json request/response which will become nightmare even for a slight change in the api). 2. for a end developer, he expects a library (like numberous libraries in python, ruby for github) to talk with github. Gnome already have javascript support for app development, so providing javascript class which wraps the github api is the simplest and easiest way. Thank you for the review. I'll try to implement GObject wrapper for Github (hopefully for gnome-builder) to get the goa-github-provider integrated. Writting GObject wrapper for webapi needs lot more time (which I'm currently lacking, because I'm a corporate slave in the day time)
gitg might also be interested in using github accounts
(In reply to comment #6) > 1. Most of the web talks in json and I feel we are yet to come-up with a good > solution to marshell between GObject-to-Json and vice-versa. (I know json-glib > is capable of doing this, but either we need to parse node-by-node or we need > to create GObject types for every json request/response which will become > nightmare even for a slight change in the api). afaik, you’re right, and we are yet to come up with a decent solution for wrapping JSON APIs. While generating an API from JSON Schema (http://json-schema.org/) is an option, there is currently no tool I know of which would do that. The best approach for the moment is probably to wrap the API manually with custom GObjects. Changes in web APIs are always going to be a problem. If you’re wrapping the API manually, you have to change your GObjects while maintaining C API compatibility. If you’re auto-generating the wrapper, you need to try and ensure the web API changes don’t cause C API changes in the generated code. Plus the inevitable withdrawing of features from the web API leaving you beached with no way of running your program as it did before. > Thank you for the review. I'll try to implement GObject wrapper for Github > (hopefully for gnome-builder) to get the goa-github-provider integrated. > Writting GObject wrapper for webapi needs lot more time (which I'm currently > lacking, because I'm a corporate slave in the day time) You might want to read this, which is a (slightly dated) account of my experiences wrapping Google web APIs. Some of it might be interesting and vaguely relevant: https://tecnocode.co.uk/2012/11/18/web-apis-a-moving-target/
few more possible consumers: anjuta, devassistant, eclipse
(In reply to comment #9) > few more possible consumers: anjuta, devassistant, eclipse Hmm, gnome-builder? :)
(In reply to comment #10) > Hmm, gnome-builder? :) That'd be nice. I do plan on providing a "Check out existing Project" feature that will search git.gnome.org/github for the project.
provider_name is "Github", it should be "GitHub".
*** Bug 780236 has been marked as a duplicate of this bug. ***
I wonder if it would be interesting to make it easier to setup a machine for GitHub access [1] ? ie., create an SSH key pair, if needed, and then add the public key to the GitHub account. I see that Seahorse can already create SSH key pairs (File -> New) and setup ~/.authorized_keys on a remote machine (Remote -> Configure Key for ...). [1] https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/24
For the sake of reference, here's the documentation for versions 3 and 4 of the GitHub API: * https://developer.github.com/v3/ * https://developer.github.com/v4/ I must say that I am finding it difficult to figure out what features are exposed through API v4, as opposed to v3. eg., I can't find the equivalent of https://developer.github.com/v3/users/keys/ with v4.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/ Thank you for your understanding and your help.