search

scripting / Scripting-News

I'm starting to use GitHub for work on my blog. Why not? It's got good communication and collaboration tools. Why not hook it up to a blog?
117 stars 10 forks source link

GitHub API questions #94

Open scripting opened 6 years ago

scripting commented 6 years ago

TL;DR -- How to find the root of a repo for the tree api, and are the content and tree APIs deprecated as of Oct 1?

  1. I'm using the contents API to do a traversal of the directory structure of a repository. It works. Here's a gist containing the code. It takes about three seconds to traverse the structure of my test1 repo. I'm thinking about using the tree API, hoping that it will be considerably faster. But I can't figure out how to get the sha for the root of the repo. Any suggestions much appreciated.

  2. There are notes on the GitHub API website about GitHub Services being deprecated starting October 1. At first I thought this applied to the API I'm using. Now I'm wondering. I'm just using the contents API. Is this part of the deprecated set? If so arrrrgh. And where can I find good sample code for getting and setting the contents of a file and doing a directory traversal.

deltab commented 6 years ago

  1. It seems that in place of a hash you can give any 'tree-ish' expression that git can resolve, including commits, branches and HEAD, and even their subdirectories:

    And yes, it is considerably faster.

    (If you couldn't do that, you could fall back on getting the repo's refs (branch heads), finding the master branch, getting its latest commit, and getting the tree from that. But that'd take multiple requests.)

  2. Nothing to do with the REST API you're using:

    GitHub Services (sometimes referred to as Service Hooks) is the legacy method of integrating where GitHub hosted a portion of our integrator’s services via the github-services repository. Actions performed on GitHub trigger these services, and you can use these services to trigger actions outside of GitHub.

    So if you wanted to send a notification to a chat channel when someone pushed a commit, or to run automated tests, or rebuild a static website, you could put some Ruby code here and GitHub would run it to trigger processes elsewhere.

    They've decided that they want to do it more consistently in future: they'll instead send HTTP requests to a URL of your choice, and you're responsible for making things happen from there.

scripting commented 6 years ago

First, thanks for the answers to both of the queries.

To the first one, your first call definitely returns a list of all the files in the repo. But I'm not familiar with the term HEAD. I assume that must come from the GIT world?

What does it mean? Is it documented somewhere? I'm happy to read, and scratch my head. I have a feeling if I understood that nomenclature I'd do a lot better with their API. ;-)

Thanks again.

rosskarchner commented 6 years ago

I think you can understand HEAD as an alias to the latest commit in the branch you have checked out. In a clone of this repo, checked out to the master branch, HEAD would be a synonym for d342e074918e7ca8a74666586f7caa8afcc1bbc0

I've been using git for years, and still found these episodes of All Things Git helpful:

https://www.allthingsgit.com/episodes/branching_and_merging_part_1.html https://www.allthingsgit.com/episodes/branching_and_merging_part_2.html

scripting commented 6 years ago

I need to explain what the app is, because it actually isn't about GIT, it's about a repo being used to host a blog. I want a way to get a list of all the editable files in the repository, so I can present them to the user in the equivalent of an open file dialog.

So if HEAD is an okay way to do that, then I'll use that. Assume that there are never any branches in the project. The repository is functioning like a file system.

I'm also okay with using the code I have that does its own recursive traversal of the repo. It turns out to be fast enough, even with a pretty active blog over a bit of time.

deltab commented 6 years ago

Assume that there are never any branches in the project.

Using git's terminology, there's always at least one 'branch' in a repo; it's called master by default. If you look in the top left of https://github.com/scripting/test1 you'll see a button "Branch: master". You can use that to switch to other branches, if you happen to have any. HEAD is (in part) the command-line equivalent of that selector.

You can use the branch name in URLs, and it's probably better to do so:

GitHub rate-limits API requests, so it's better to reduce the number sent when you can. (Also, why do more than you need to?)