I am using github to share a set of SPARQL queries:
http://www.boisvert.me.uk/opendata/sparql_aq+.html?file=specific%20sensor.txt
Currently the simple work allows end-users to access queries stored on the github repository, but ultimately I want to allow them to also modify the queries, as with a pastebin, and make use of the repository to better manage the shared system. Ideally I would want end-users who may not be very tech-savvy, to be able to make minor changes to queries to an open, linked data endpoint: so to keep the technology barrier low.
My problem is this: how best to structure the github project and exploit the API to make the most of the available information? I can think of different points:
Currently the project (https://github.com/boisvert/unshaql) holds client code and example queries. Does it make a difference to create an independent project (separate from the web client code) for SPARQL queries?
I would use directories within the project to classify/tag queries, and file names to title them. Are there better alternatives? It strikes me that a hierarchical structure is not a good fit to tags.
When end-users save, a simpler (and cruder) option is to allow them to push their file into just one branch, which holds the examples. A better engineered one would be to allow them to use their github credentials to fork the set of SPARQL queries and edit theirs, but with unaware users, how do I avoid creating a mess?
I think that a rigular Github repository is a rather bad fit for this kind of content. If your users have a GitHub account, you should probably use Gists instead: https://help.github.com/articles/about-gists/ I never used this myself, but it seems perfectly adapted to what you are planning. Your site could become a DB of tags over user-provided gists. That would however lock you into GitHub-specific solutions.
Even if you go for a regular repository, you should not allow the users to commit into the repository hosting your code: that would be a serious security hazard as you won't be able to control the parts of the repository to which they are allowed to commit.
If you setup two repositories, it's rather easy to have the code of a webpage in a repository, and the code automatically commited in another repository (under an anonymous identity so that your users don't have to create a github account).
Also, note that the oauth token should never be stored in a public repository (or the GitHub robots will invalidate it in a matter of hours).
See Hiding GitHub token in .gitconfig for a solution to this sub-problem.
Related
I'm working on a project, and I want to authenticate into, and use the Github API, in order to make some modifications to the project. Simple operations such as creating a new branch in the existing repo, creating a pull request etc., are some of the actions I am planning to do.
For the authentication to happen, I understand we can use a username/password combo, or create a personal access token(which is best practice). For now, I want to test it using username and password. I am looking for ways to do that, and some solutions suggested using GithubClient library.
For using this library, I am trying to understand..what is the dependency/dependencies I need to include for this? And how can I use GithubClient for this? I am struggling to find online resources for this, so reaching out here for any answers/documentation on this process.
I'm trying to figure out, if it is possible on GitHub to give someone read-only access to a specific private repository, allow only to see content, without the possibility of collaboration to contribute with change in the code or readme markup
This is only possible for private repositories managed by organisations.
https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization
If your repository is an organisation one, you can visit:
https://github.com/`OWNER`/`REPO`/settings/access
You can then add a collaborator and set their permission level to:
Read: Recommended for non-code contributors who want to view or discuss your project
Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
Write: Recommended for contributors who actively push to your project
Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
Is there a way to view repository traffic for all repositories on your account at the same time? (without creating your own custom dashboard using the Github API). It would be very convenient. I suspect a bash script might do this without too much effort (e.g. get all repo names, get the traffic/stars stats for each repo in the list). But I want to be sure something obvious doesn't already exist before writing anything myself
I am not ware of any native dashboard that would aggregate multiple GitHub repositories into one convenient view.
You would therefore have to rely on third-party scripts, such as, for example, nchah/github-traffic-stats (Python)
Get statistics on web traffic to your GitHub repositories.
Since it is limited to the last two weeks, you might have to record those statitics over time (example: Microsoft/GitHubTelemetryParsor)
I am trying to get all repositories whose language was Java but had changed to Kotlin and vice versa.
Does anyone know if it's possible to filter these repositories with the Github api?
If you are looking to compare before/after, in terms of a programming languages for particular GitHub repos, I'm not sure you can do that short of having a big-data project.
If you want to filter GitHub repos by programming language, the GitHub API documentation states:
Suppose you want to search for popular Tetris repositories written in Assembly. Your query might look like this.
curl https://api.github.com/search/repositories?q=tetris+language:assembly&sort=stars&order=desc
Also,
Checkout my open-soure project Git-Captain, which may help you.
It's an open-source web-application built with Node.js utilizing GitHub API to find, create, and delete a branch throughout numerous GitHub repositories.
Can be setup for organizations or a single user.
I have a step-by-step how to set it up on a server to communicate with the GitHub API.
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.