Setting teams in the global settings.yml wipes out all teams in all repos in the whole org

[justinmchase]

Problem Description

I went to add a team to all repos, by setting one team in the settings.yml file into the teams section it wiped out all of the teams in all the repos in the whole org, except for those who also had suborgs and/or individual repo files.

What is actually happening

It calculates changes for the settings.yml to affect all repos, for each repo it calculates it should have only that one team.

What is the expected behavior

I would expect any repo affected by a change to the settings.yml file should have additive changes only. If it also has a suborg and/or repo file then it could be definitive but with only the settings file being applied it should be additive.

Optionally, there needs to be a way to define the behavior for teams such as:

teams:
  add: 
    - name: global-security-team
      permission: read

Error output, if available

N/A

Context

Are you using the hosted instance of probot/settings or running your own?

my own

If running your own instance, are you using it with github.com or GitHub Enterprise?

enterprise

Version of probot/settings

2.0.21-rc.8

Version of GitHub Enterprise

not sure.

[svg153]

I think the main idea of this project is that the project acts as "A single point of truth" in everything it can manage. Except for labels, because many apps create their own and it would be more difficult to manage.

It is true, that because of this, the migration is more "complex". If the tool provided a way to generate the configuration files taking what is configured in GitHub, it would be much simpler. As this is not the case, you can always make a quick script.

But, it would be nice if there was something in the README.md advising how it works and this possible problem.

PD: possible duplication with #350

[justinmchase]

I don't mind that it can set the teams precisely, overriding what teams are set in each repo. If that's what I wanted to do, then it would be a huge life saver.

But it seems like in the settings.yml, more often then not its not really practical to set the teams for all the repos to be just that one set. If they don't also have a matching suborg or repo specific file then its pretty aggressive. I can't have any shared teams in that file.

As you said the labels have include/exclude logic because "many apps create their own", but similarly repos tend to create and assign their own teams. Managing that at the settings.yml file seems not totally practical; they'll all be the same.

[svg153]

I may have misunderstood you. But within each file associated with a repository, you can put the teams you want to have permissions to that particular repository. Example:

We have this config:

file and folder tree

# admin repo 
.github
├── repos
│   ├── api.yml
│   ├── devs-team.yml
│   ├── infra.yml
├── settings.yml

settings.yml:

repository:
  auto_init: true
  private: true
  visibility: private
  ...
teams:
  - name: management
    permission: admin
...

api.yml:

repository:
  name: api
teams:
  - name: infra
    permission: admin
  - name: devs
    permission: push
...

devs-team.yml:

repository:
  name: devs-team
teams:
  - name: management
    permission: pull
  - name: devs
    permission: admin
...

infra.yml:

repository:
  name: infra
teams:
  - name: infra
    permission: admin
  - name: devs
    permission: push
...

And this would look like this:

• NOTE: management has admin permissions on all repositories.
• The api repository:
  • management has admin permissions (inherited)
  • infra has admin permissions
  • devs has push permissions
• The devs-team repository:
  • management has pull permissions (downgraded).
  • devs has admin permissions
• The infra repository:
  • management has administrator permissions (inherited)
  • infra has admin permissions
  • devs has push permissions

---

What you cannot do as far as I know is to configure the members of a team, nor directly configure which repositories the team has access to.

[justinmchase]

Right I get this but, lets now imagine you have the same files as above but your organization has 1,000 repos in it from a ton of different teams.

Three of your repos are setup correctly, awesome! But sadly when you created that settings.yml file, 997 of them just had all their teams wiped out and replaced with only management: admin :( which is what just happened to me.

Its not really reasonable to expect every single team to create a suborg / settings file for all 1000 repos before you can even turn safe-settings on at all.

So therefore what we have to do is to make everyone put their teams in the suborg and we can't have any in the top level settings.yml file at all and there is no way for us to globally add the management: admin team to all repos.

Unless the global settings file is treated a little differently or has an include/exclude sort of behavior for the teams.

[decyjphr]

@justinmchase @svg153 would it make sense to treat Teams and Collaborators differently in that, safe-settings will not remove the existing teams by default, and only do so when there is a force flag? Basically we will make this function nop by default.

[justinmchase]

Well, that wouldn't be ideal either... I don't want people adding teams or granting access outside of the settings.

In my mind the logic should be something like this:

psuedo-code

for repo in affected_repos:
  global_settings = read(.github/settings.yml).teams
  suborg_settings = filter(read(.github/suborgs/**/*.yml), r => glob(r.name, repo.name)).teams
  repo_settings = read(.github/repos/{repo.name}.yml).teams
  
  if global_settings and not suborg_settings and not repo_settings:
    teams = distinct(concat(repo.teams, global_settings))
  else if global_settings or suborg_settings or repo_settings:
    teams = distinct(concat(global_settings, suborg_settings, repo_settings))

  if teams:
    api_put(teams)

[robandpdx]

Removing teams and users that are not specified in a config file is the desired functionality. This is not a bug. If you want to exclude repos from safe-settings you can use the deployment-settings.yml file to specify repos that safe-settings should ignore. See here for more details.