REQUEST: Create kubernetes-sigs/sigs-github-actions

[helayoty]

New repo, staging repo, or migrate existing

New repository

Is it a staging repo?

no

Requested name for new repository

sigs-github-actions

Which Organization should it reside

kubernetes-sigs

Who should have admin access?

@kubernetes/sig-contributor-experience-leads

Who should have write access?

@kubernetes/sig-contributor-experience-leads

Who should be listed as approvers in OWNERS?

Each dedicated sig folder will have its sig leads as OWNERS

Who should be listed in SECURITY_CONTACTS?

@kubernetes/sig-contributor-experience-leads

What should the repo description be?

Repository for GitHub actions and artifacts related to all sigs in Kubernetes.

What SIG and subproject does this fall under?

@kubernetes/sig-contributor-experience-leads

Please provide references to appropriate approval for this new repo

Based on the slack discussion, this issue, and kubernetes/community#7316

Additional context for request

Following the best practice from sig-auth:

• [sig-auth] New project board and use github actions for board sync kubernetes#111963
• https://github.com/kubernetes-sigs/sig-auth-tools
• REQUEST: Migrate puerco/release-actions #4170 (comment)
• Tools needed to update Github dashboard.

@kubernetes/sig-release-leads @kubernetes/sig-scheduling-leads @kubernetes/sig-auth-leads

[alculquicondor]

@mrbobbytables it feels like there could be a more generic repo for things like this.

Are you aware of any prior work?

[helayoty]

I'm happy to work with @kubernetes/sig-auth-leads to unify the already created repo and add a new GitHub action to it instead of maintaining a new one.

[kerthcet]

/cc
Happy to see that.

[helayoty]

Based on our discussion with @kubernetes/sig-auth-leads today in the biweekly meeting, it would be nice to have a new repo that can host all SIGs Github actions. The repo can be with the ./github/sig-<name> folder structure so each sig can own and maintain their list of GH actions.

The proposal is to get @kubernetes/sig-contributor-experience-leads to own the repo. Appreciate your feedback.

cc @liggitt @enj @aramase @kubernetes/sig-scheduling-leads

[aramase]

Based on our discussion with https://github.com/orgs/kubernetes/teams/sig-auth-leads today in the biweekly meeting, it would be nice to have a new repo that can host all SIGs Github actions. The repo can be with the ./github/sig- folder structure so each sig can own and maintain their list of GH actions.

I would be happy to modify the code to make it generic enough and add it to the new repo when it's created, so each SIG can use it by passing the config.

[mrbobbytables]

FWIW - there are a bunch from kubebuilder that are being reused all over the place too. I do think consolidating makes sense - it also means the repo owners (likely github admins) could rapidly make a change if one is implemented in an insecure way.

[cpanato]

+1 i think that will be really useful

[MadhavJivrajani]

+1 to the idea with ContribEx hat on
Based on the repo structure described in kubernetes/community#7316, I think we should also move the GitHub admins to be root approvers for this repo.

All sig leads

Under "Who Should Have Write Access", just making sure I'm understanding this correctly, write access is given to SIG leads that have actions hosted in this repo, correct?

[helayoty]

Based on the repo structure described in kubernetes/community#7316, I think we should also move the GitHub admins to be root approvers for this repo.

Agree

Under "Who Should Have Write Access", just making sure I'm understanding this correctly, write access is given to SIG leads that have actions hosted in this repo, correct?

@medyagh, ideally, the write access should be for all sig-leads.

[MadhavJivrajani]

the write access should be for all sig-leads.

@helayoty - I'm not sure about this mainly for the reason that at least initially, the number of sig leads will be far greater than the number of sigs hosting actions, and I'm a little concerned about giving unnecessary write access, especially to a repo hosting actions, I could be missing something here though.

One downside of not having all sig leads and only having sig leads who actually have actions hosted is - when we onboard a new sig, the leads would need to be added explicitly (which is preferable imo). We could document this in the README and have an issue template for any sig that wants to start hosting actions here where a checklist item would be GitHub Admins to give SIG leads write access or something along those lines.

@Priyankasaggu11929 @nikhita wdyt?

[Priyankasaggu11929]

the number of sig leads will be far greater than the number of sigs hosting actions, and I'm a little concerned about giving unnecessary write access, especially to a repo hosting actions

Totally agree! Currently, I don't think all sig leads should have write access by default. The repository will (eventually) have sensitive information needed for running GitHub Actions. Giving such broad write access would expose that sensitive info to people who don't need it right now (and might cause unnecessary security issues).

My suggestion is to onboard sigs when there is actually a requirement.

We could document this in the README and have an issue template for any sig that wants to start hosting actions here where a checklist item would be GitHub Admins to give SIG leads write access or something along those lines.

+1, this way we (SIG ContribEx / GitHub Admins) can keep track of new sig leads joining the repo.

[alculquicondor]

Very few people need write access, so perhaps only the SIG Contrib Ex leads.

The other leads that already want to have actions in this repo can be approvers in the OWNERS file

[cpanato]

agree, there is nothing much to change in this repo, so we can limit the access to be easier to manage

[helayoty]

Sounds good. Let's limit the write access to Contrib Ex then

[MadhavJivrajani]

/assign
Thank you for the discussion, I'll go ahead with creating this repository.
@helayoty - I've edited the description for write access according to #4218 (comment)

[MadhavJivrajani]

The repo has been created here: https://github.com/kubernetes-sigs/sigs-github-actions 🎉

The following PRs have been created to add GitHub teams and subproject documentation:

• contribex: Add teams for sigs-github-actions repo #4293
• contribex: Add sigs-github-actions subproject community#7364

Additionally, in the repo, root approval and SECURITY_CONTACTS are listed as ContribEx TLs + GH Admins.

Closing this issue now, thanks!
/close

[k8s-ci-robot]

@MadhavJivrajani: Closing this issue.

In response to this:

The repo has been created here: https://github.com/kubernetes-sigs/sigs-github-actions 🎉

The following PRs have been created to add GitHub teams and subproject documentation:

• contribex: Add teams for sigs-github-actions repo #4293
• contribex: Add sigs-github-actions subproject community#7364

Additionally, in the repo, root approval and SECURITY_CONTACTS are listed as ContribEx TLs + GH Admins.

Closing this issue now, thanks!
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.