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
Related
is there a way to give a GitHub token only access to pull the latest release from my private GitHub repository. for updating a electron application. I don't want the token to have access to anything else but the latest release only
No, this is not possible. Tokens are generally scoped much more broadly than that (usually to your entire account), and even for ones that are scoped more narrowly, they'd cover at least all of the releases for the repository, if not the rest of the repository contents as well.
If you're trying to distribute software that's in a private repository, you should use some sort of CDN or cloud bucket for doing that (over HTTPS) and implement a suitable digital signature scheme to prevent rogue updates.
Is there any way to restrict the release download only to registered users, for a public repository?
No, there isn't. Access to the releases and release assets are allowed to exactly those people that have access to the repository. For a public repository, that's everyone.
If you want to restrict the set of users who can download release assets, you'll need to either restrict access to the repository or use a different solution. For example, if you want to restrict binaries to paid users, you'll need to build something yourself.
I have a hook configured in Github in Organization level which applies all the projects underneath of that organization by default. But I want to eliminate this hook for specific projects of this organization. Is it possible to set up somehow in Github Enterprise?
No, this isn't possible. You will either need to configure the individual repos to have the hooks you need, or have the org-level hook be smart enough to ignore the things it does not need.
Perhaps you can write a simple webhook forwarder that has the logic you need?
I'd like an organizational private (as in not shared with the internets) repository to be accessible to all organization members, regardless of teams. Preferably for both read and write, but only read is also acceptable.
I might be missing something, but without creating (and therefor maintaining) an 'everyone' team I can't think of a way to configure that.
Thanks!
You can achieve this by:
Create a private repository in the organization
On the organization settings define the default access level to:
Read (every member of the organization has read access)
or Write (every member of the organization has read/write access)
Note that to create a private repository in an organization you need to be on a paid plan.
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.