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.
Related
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
My team is implementing Azure DevOps 2019 server on prem. There is a requirement to give all valid users permission to create shared queries in all projects. Is it possible to set permissions for shared queries at the collection level?
The permissions for shared queries are managed within the queries itself, and whilst the default permissions allow for the built in Project Administrators (and Project Collection Administrators) group to contribute shared queries, you probably don't want to move everyone into one of those groups.
Instead, you would have to go into each team project, go to the queries, and edit the security on the root:
]
You can then grant permissions by group (built in or custom):
(So above, I've changed the built in "contributors" group to allow them to Contribute to queries, which allows them to create new)
Depending on how many team projects you have or create, will depend how manageable the is as a workaround, but it is safer than making everyone an admin 😉
Query is a project-level function, so if you want to access Shared Queries in Peoject B from Peoject A, it may not be possible.
To access Shared Queries, you need to be a member of the team that has permission to access the query, but the team is limited to the project, so shared queries cannot cross projects.
If you really want to share queries between projects, you can make a feature request here:
Developer Community
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.
We are looking at adopting Azure DevOps' hosted and cloud-based solution. However, organization names appear to be global in namespacing. Therefore, private internal project organization names become exposed to enumeration attacks and make it difficult for us to organize our projects.
A very simple example would be that we have an internal organization called Finance. Since it's global namespacing, we would have to call it Acme-Finance. Then we'd have to have Acme-Infrastructure, Acme-ProjectX, Acme-Project-Y. That is very messy.
Gitlab, as an example, has an infinite set of sub-organizations that you can create.
We could solve this with the on-premises version and using Collections, but it would lag behind all of the updates and functionality in the cloud version.
My application calls GitHub API so I have to store GitHub token somewhere. I don't want to publish my token to public repository. I decided to store it in environmental variables. Disadvantage of environmental variables is that I have to set it correctly on all machines (localhost, codenvy, jenkins ...)
Is there better solution?
You can easily move it to Properties file and distribute it on all systems you need. If the security is matter for you, consider encryption of actual values for such file.
Hope it helps!