GitHub Enterprise: ansible-community & ansible-collections GitHub Org

Project Discussions
1

Hi folks

Summary

The ansible-collections & ansible-community and other Ansible related GitHub Orgs will move under Red Hat’s GitHub Enterprise agreement. This should not be a visible change, though we want to give our community a heads up, just in case you notice any differences

This will happen week of 16th November

Details

There are many reasons why we are making this change, for the community the benefits are:

  • Increased GitHub Runner capacity
  • Benefit of Red Hat’s format support agreement with GitHub
  • Access to GitHub’s Enterprise auditing and security features
  • CodeRabbit

Out of scope

Questions

Feel free to ask

3 Likes
2

@SteeringCommittee one issue I’ve just become aware of is that Outside Collaborators (non Red Hatters), can’t be members of teams. This is a technical requirement. It’s not an issue currently as the GitHub Orgs are stand-alone, and there’s no concern about accidental access to other Red Hat repos under the Enterprise.

I’ll need to audit the existing teams we have in the upstream GitHub Orgs, though I believe this would impact the Steering Committee GH team, which we use for repo permissions and code owners. We can script that.

Do we ever use @steeringcomittee as a comment?

Is having the “teams” and permissions defined in config files ok?

3

Right now Sign in to GitHub · GitHub does contain a few community members, but only a subset (IIRC the reason why not all were added was because every person costs money). Sign in to GitHub · GitHub is more complete (though it misses @dbrennand and @acozine), and Sign in to GitHub · GitHub is almost complete (the rotating core member is missing).

Also right now being members of the team means whether you have commit rights in some repos, like ansible-documentation, which also means that while we could manually add all SC member GH usernames in ansible-documentation/.github/CODEOWNERS at devel · ansible/ansible-documentation · GitHub for all the lines, and you need to manually add all the people to every repo they should have write access to. It would be good to automate this, otherwise this is a security and maintenance nightmare. (It might still be, depending on how good the automation is.)

Also right now we already have the situation that not all Ansible release managers (and SC members in general) have appropriate access to ansible/ansible-documentation, which means that for example @mariolenz cannot trigger the workflow that creates the porting guide PRs, and cannot merge these PRs. (Fortunately @gotmax23 and me have access, and @oranod is around to help, so this wasn’t a big problem yet, but it’s not really great either.)