Questions about project usage

[grossag]

I am looking to integrate this for my company's EMU account and have a few questions.

First, the README says: "We recommend that you have a dedicated GitHub organization for your contributions. This will allow you to keep your contributions separate from your organization's daily operations." Do you have any more guidance as to why this is necessary? I had previously expected to do mirroring into our main engineering organization and put this integration's Probot app user in as exempt from our push protections. The reason why this is important for us to sort out is that Conan to build our software. Conan needs to clone the OSS mirror as part of its build process, but GitHub EMU accounts have very severe limitations in their ability to clone repositories across organizations. The most you can do is to clone GitHub repos within your org using actions/create-github-app-token. We may have other repositories that also need to clone these OSS mirrors. So given GitHub's access requirements, we will need to ensure that whatever proprietary build repositories we have will be in the same org as the OSS mirrors.

Second, is there any configuration that controls the settings of the forked repositories that are created in our EMU? The most immediately important one is to disable Actions for these repositories. Otherwise, OSS mirrors like openssl will start requesting builds on every push, which very quickly burns through our EMU's quota of build runner minutes. And we will be building these OSS mirrors separately in Conan, so we don't need the OSS mirrors' actions to run.

Third, I have two questions related to this part of the README: "Currently, any member of the organization can access the app and create additional private mirror repositories". a. Is there any writeup detailing the user experience of this private mirror creation, showing how people request these? b. Are there any plans to allow us to limit this to org admins? I am not necessarily asking for this feature yet, but I was just curious.

[ahpook]

Hey @grossag these are awesome questions! Thank you for the interest - let me take them in turn. And please reach out if you want to chat live, you can reach me at gh.io/meet-with-ahpook

1. the main reason we recommend having a separate organization for your open source work is to keep security boundaries clear, especially if you have external collaborators on the public forks. But just to be clear, we'd fully expect the mirrors (the right hand column in the attached screenshot) to be inside the EMU org, and it's the middle column (public forks) that we're suggesting be in the open source organization.
2. Currently, the ICF app only manages the settings around push protections on the mirrors it creates. Newly created mirrors are subject to organization wide settings enforcement, though. And it might be possible to make a hook for additional settings configuration after a mirror is created - though I fear this could get complicated quickly if people want different settings per upstream project rather than globally... Gotta think about this one more!
3. (a) The Getting started doc goes through the new mirror creation UX in detail, does that help? and (b) is a whoopsie, this should be updated - we now have an allowlist of userids which should be allowed to access the app.

Here's the screenshot showing the flow across orgs I referenced above.

[grossag]

That is really helpful, thank you!

That sounds good that private mirror repos can be in the same org as other sources. That addresses my concern. No issues with putting the public forks in their own orgs.

As some context about why I want to disable actions by default for private forks, another team at my company was mirroring OpenSSL and I found that one build on one day used 1000 minutes of our 50000 minute monthly allotment! We didn't need those builds at all, so we disabled them.

One approach that would work fine for us would be to allow a configuration setting allowing us to set "Disable actions" as shown here: (which AFAICT under the hood uses API https://docs.github.com/en/rest/actions/permissions?apiVersion=2022-11-28#set-github-actions-permissions-for-a-repository with enabled=false). This would apply to all newly-created private forks and be respected only at repo creation time. Then we could decide if we wanted to go in afterwards and enable actions, but that would be a step afterwards that we could do manually.

[ajhenry]

I can add functionality to have a toggle to disable actions on the mirror creation screen. Will create an issue here 😄

[grossag]

I can add functionality to have a toggle to disable actions on the mirror creation screen. Will create an issue here 😄

Honestly I'm not sure if I trust people to choose the correct option 😄. I would love it if we could just disable it by default for us.

[ahpook]

I'm gonna close this issue as I think the initial questions have been addressed and we've spun up more specific issues for the enhancement requests - please feel free to comment/reopen if i've missed something @grossag !