Repo create with team should give the team Manage instead of Read access

[yrsurya]

Describe the feature or problem you’d like to solve

We are having Base permissions for Members as Read so that we can set boundaries and utilize teams to manage repos.
But while using gh cli to create a repo and allow it to team getting read only access where I attached screenshots
A clear and concise description of what the feature or problem is.

gh repo create $ORG_NAME/test --private --team $TEAM_NAME

Proposed solution

It would be nice if we can add permissions level inlcuded in gh cli so that entire members in team can get write access
How will it benefit CLI and its users?

It will be beneficial so that no need to update again from GUI to allow access to that repo for remaining members in that team.

Additional context

We don't want to allow base permissions to write which will give write permissions to ALL repos in this ORG fro ALL Members
Add any other context like screenshots or mockups are helpful, if applicable.

[mislav]

It would be nice if we can add permissions level included in gh cli so that entire members in team can get write access

@yrsurya Thank you for the feature request! 🙇

Your use-case totally makes sense: to be able to override the base permission of "read" to something else while creating a repository on behalf of a team.

However, this does not seem to be available in our API, neither is the CLI able to issue an subsequent API request to change the permission for the new repo from "read" to "write" after the repo was already created with "read". Unless I'm missing something, this would require us to create a new platform API for this (which usually takes a while) in order to support this feature.

[yrsurya]

curl -v --request POST \
  --url https://api.github.com/orgs/$ORG_NAME/repos \
  --header 'accept: application/vnd.github.nebula-preview+json,application/vnd.github.baptiste-preview+json' \
  --header "authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN" \
  --data '{ "name": "'"${REPO_NAME}"'", "description": "This is your first repository", "homepage": "https://github.com", "private": true, "has_issues": true, "has_projects": true, "has_wiki": true, "team_id": "${TEAM_ID}" }'
curl \
  -X PUT \
  --header "authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/orgs/$ORG_NAME/teams/$TEAM_NAME/repos/$ORG_NAME/$REPO_NAME \
  -d '{"permission":"push"}'

I am trying this but not working though as of now but I believe api already exists . Something to start with

[mislav]

@yrsurya Thanks for trying this out! Is it the 2nd request that fails? Can you share with us the server response?

[yrsurya]

github.log

So I am trying with a Member PAT who added to that team but not with maintainer role

[mislav]

@yrsurya Thanks for sharing!

It looks like this PAT doesn't have access to create repositories for this team in the first place. Maybe this needs to be solved first before we can get to the problem of creating the right permissions for the new repo?

[yrsurya]

Member is not maintainer of that team just part of team which doesn't allow me to do this. once I made Maintainer I can execute that without issue and achieve what I am trying to do.

[ryenus]

Hello, any update on this? maybe it's time to resurrect this? @mislav

[masonwaters36]

It would be nice if we can add permissions level included in gh cli so that entire members in team can get write access

@yrsurya Thank you for the feature request! 🙇

Your use-case totally makes sense: to be able to override the base permission of "read" to something else while creating a repository on behalf of a team.

However, this does not seem to be available in our API, neither is the CLI able to issue an subsequent API request to change the permission for the new repo from "read" to "write" after the repo was already created with "read". Unless I'm missing something, this would require us to create a new platform API for this (which usually takes a while) in order to support this feature.

Hello, I was wondering if there have been any changes made to this?

[ecs-hk]

After a discussion thread with @mislav (and also reviewing code in the gh-repo-collab repo), I have found a workaround that may be of interest to others.

First, create the repo:

gh repo create someorg/myrepo \
        --add-readme \
        --team='goodguys' \
        --internal

This will create "myrepo" (within "someorg") and will add the existing "goodguys" team with Role:read.

Next, make a second call to change "goodguys" team to have Role:maintain (or whatever permission you want).

gh api -X PUT '/orgs/someorg/teams/goodguys/repos/someorg/myrepo' \
        -f 'permission=maintain'

Voila - workaround done. Now the "myrepo" has "goodguys" with Role:maintain.

[ edit: This seems to be the same pattern as earlier in this issue thread, except using the GitHub CLI rather than the REST API. This approach is working for my case. ]

[marcotrosi]

Hello everyone, wanted to ask about the status of this relatively old issue.
We have the issue that we want create repos using gh and assign the repos to N teams (5 teams in my case).
But the manual doesn't show how to configure also the permissions for each team (Read,Triage,Write,Maintain,Admin).

or maybe even better it would be nice to get gh team as a command, to configure various team related configurations. There we could then add the repos with proper permission level.

[mislav]

@marcotrosi Have you tried the gh api workaround as suggested by @ecs-hk in their last comment?

[marcotrosi]

@marcotrosi Have you tried the gh api workaround as suggested by @ecs-hk in their last comment?

hello @mislav , thanks for your feedback.
Haven't tried yet, will do for sure, I only thought I'll give my question a shot since the issue is still in "open" state.

[ghost]

This does not work when using access token (fine-grained, or classic)

gh api -X PUT '/orgs/someorg/teams/goodguys/repos/someorg/myrepo'
-f 'permission=maintain'

I’ve submitted an issue. (it’s an API issue)

[Kurt-Larson]

Hi all,

I'm not trying to take over this Issue, but I have a complementry use case that I think that could enlighten a solution that can solve many use cases. So, I'm posting it here instead of creating a separte Issue.

We use GitHub Enterprise Server, currenlty v3.10, with Jira Cloud. Our developers absolutely depend on an integration between Jira and GitHub. We use the GitKraken Git-to-Jira Integration (GJI) for this. This integration runs on the Jira side and requires GitHub credentials to do GitHub operations on behalf of the Jira user. We use a GitHub "Service" User that is dedicated to just this integration with credentials for it stored in the integration. In order to use the features of this integration it needs to be able to create branches, delete branches, create Pull Requests, read commit info. The net permission required is effectively "maintain" Role that is the GitHub "Service" User must have on all Repositories that Jira Users can interact with. That's all Repositories in the GitHub Organization for us. It's not difficult for us to execute a script that calls the GitHub Rest API to list all Repositories and loop over them granting a GitHub Team the "Service" User belongs to "maintain" Role on those Repositories.

Our challenge comes when someone creates a new Repository. There is no mechanism for a GItHub customer to configure a default set of permissions to a defined set of Team(s) or User(s). This is creating a bad GitHub developer experience where they can create the Repository, they can commit code to it, and push that commit to GitHub just fine. They can also create and/or update Jira Issue related to the same work. However, they can't use the Jira integration to create a branch for their development work in the Jira Issue, can't see the commits pushed to the GitHub Repository in the Jira Issue, or any other GitHub operation that the Jira Integration can do. This is because they created the GitHub Repository, but the Team that needs the "maintain" Role's permissions doesn't get granted.

So, because the developers can create the GitHub Repositories and use them, but typically and also in our use case, don't have the permission themselve to grant permissions for Teams and Users to the newly created Repositories, this is creating a bad GitHub developer experience for them. To solve this problem we need a way to configure at least one Team to automatically be granted the "maintain" Role to the Repository, regardless of how the Repository is created. IOW, the Repository creation REST API will not work of this use case for 2 reasons. One, not all ways to create a Repository cause Team permissions to be added, so far only the REST API call does this. The GitHub web Ui doesn't do this nor does any other Repository creation mechanism. Two, the REST API call hard codes only granting "read" Role permissions to the Team specified in the REST API call. Even if the REST API call were to be extended to support specifying a Role along with the Team to grant access to the Repository being created, that would not support our use case. It may support other use case describe earlier in this Issue though.

So, I'm requesting that GitHub provide an Organization confirguration where a set of default permission can be specified for any Repository that gets created in the Organization such that regardless of how or when the Respository gets created those permissions are applied to the Repository at creation time. I don't think this a too big an ask because GitHub has already implemented a different flavor the default Repository permissions for all Repositories that get created in an Organization. Under the Organization configuration for "Code security and analysis" there is a "Security Managers" setting that takes a Team as input and grants that Team "read" Role to all Repositories that already exist in the Organization and all new Repositories as they get created. So, the "Security Manager" feature is already doing all the work that is needed. All that needs to implemented to support this request is another way to configure the Organization to specifiy Team(s) and matching Role(s) to grant to all Repositories that reuses the same code that grants the "Security Managers" Team permissions.

I believe such a feature will satisfy most if not all the use cases outlined in this Issue. Please consider it for implementation as soon as possible. Thank you!