CSV

[SoniMail]

I was thinking, what if you add an option where we could import/export a .csv file where we could set the date and time for each trophy? I think that might ease some steps for games with big trophy lists

[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 !