github-community-projects / internal-contribution-forks Goto Github PK

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.

Is your feature request related to a problem?

GitHub has a feature for collaborating in a temporary private fork to resolve a repository security vulnerability. Developers within enterprises may want to collaborate on resolving security vulnerabilities in open source. They may be particularly interested in fixing the vulnerability due to impact within their enterprise or may have necessary expertise to contribute a vulnerability fix to the project.

Describe the solution you'd like

Support temporary private forks for resolving a security vulnerability within Internal Contribution Forks, if possible.

Describe alternatives you've considered

I'm not familiar with how temporary private forks for resolving a security vulnerability actually work within GitHub. There may be limitations in how they sync back to a user or organization repository that does not align with how ICF supports syncing back to a public fork.

Additional context

No response

Summary

We need a way to configure default settings for users of ICF. Taking this issue as an example: #71

We should use something like https://github.com/github/safe-settings for managing the input and behavior of these settings.

Team

Corresponding Work

• Investigate github/safe-settings and see what it would take to integrate
• Investigate other alternatives to safe-settings
• Add sensible defaults for the settings
• Add documentation for setting up settings

Supporting Documentation

https://github.com/github/safe-settings

https://github.com/apps/settings

Is your feature request related to a problem?

Developers may need to work on multiple open source contributions to the same repository at the same time. Some reasons why this may occur include

• The review cycle for open source pull requests may take some time
• Making small, well scoped pull requests is often considered a best practice in software engineering
• Open source projects may ask that large pull requests be split up so that they are smaller in scope, easier to review, and easier to revert when necessary
• Developers may be familiar with stacking changes on top of each other and may want to land a stack of pull requests one after the other

When working outside of Internal Contribution Forks today, developers can make separate branches on their fork for each contribution they want to make. This allows multiple contributions to flow through their fork at a given time. Developers can also make branches on their fork from a source branch other than the default branch, allowing them to make a branch off of an existing branch on their fork. This enables stacked pull requests.

Describe the solution you'd like

Through Internal Contribution Forks, support multiple branches in the public fork that sync to corresponding branches in the private repository for internal contributions. Instead of assuming the default branch of the public and private repositories are used for a contribution, these branches need to be configurable.

Specifically, the following features should be supported or considered

• Developers should be able to make a branch through ICF on their private fork corresponding to a given branch on their public fork
• ICF should support branch protections or repository rulesets for a configurable set of branches on the private repository
  • A branch pattern could be configured in ICF for matching branch protections or repository rulesets
  • ICF would need validation in the UI / API that only protected branches can be synced back to public mirrors
• Some form of branch syncing is likely necessary necessary, where ICF should be able to update the public and private repository branches, that correspond to an existing contribution, from the upstream open source repository when another contribution merges
  • Some open source projects require clean history when contributing and disallow merges in pull requests. Developers may otherwise encounter conflicts and need to recreate their fork and corresponding PR from scratch when their contribution branches become out of sync with the upstream open source repository

Describe alternatives you've considered

Only support concurrent contributions through separate forks. Users will need to manage multiple remotes in their local git config and target the appropriate remotes in git commands, which may get confusing and lead to errors. It is unclear if stacked branches or pull requests would be supported with this model.

Additional context

Here's a helpful blog post on stacked pull requests that walks through the flow for making them. Here are some additional references that may be helpful.

• https://benjamincongdon.me/blog/2022/07/17/In-Praise-of-Stacked-PRs/
• https://www.michaelagreiler.com/stacked-pull-requests/

Is your feature request related to a problem?

No response

Describe the solution you'd like

Reading from the app manifest is tedious, there is an option to have the values prepopulated in the URL so when they visit the page the user does not need to select any permissions.

https://docs.github.com/en/apps/sharing-github-apps/registering-a-github-app-using-url-parameters

Describe alternatives you've considered

No response

Additional context

No response

The section https://github.com/github-community-projects/internal-contribution-forks?tab=readme-ov-file#github-app has a link:

There's an App manifest in the repo that lays out all the permissions and webhook events needed and can be found here.

but that file doesn't seem to exist anymore.

Describe the bug

There's currently a known issue where EMU integrations are not allowed to create repository rulesets. We need to fallback to using branch protections until this issue is resolved.

To Reproduce

When making rulesets in an EMU org, you will be met with the following error:

{"data":{"createRepositoryRuleset":null},"errors":[{"type":"FORBIDDEN","path":["createRepositoryRuleset"],"extensions":{"saml_failure":false},"locations":[{"line":1,"column":11}],"message":"Unauthorized: As an Enterprise Managed User, you cannot access this content"}]}

Expected behavior

We need to use the old behavior of branch protections when this error occurs

Screenshots

No response

Additional context

No response

This is an issue for supporting GHES with ICF (if even possible).

Describe the bug

We updated to Probot 13 and this broke payload verification

probot/probot#1974

probot/probot#1973

To Reproduce

Send any github payload to the app

Expected behavior

Payload shouldn't be parsed before being verified

We need to disable body parsing for the webhook endpoint

Screenshots

No response

Additional context

No response

Summary

We received some great designs from @stvehayes so we now need to implement them.

The completed designs are in a figma file but an attached SVG can be found in this issue below.

Team

Corresponding Work

### Tasks
- [ ] Replace ICF pages router with app directory
- [ ] Create a standard layout page
- [ ] Customize NextAuth login page
- [ ] Fix issue with authentication of JWT being longer than expiration of github token
- [ ] Implement new designs for the rest of the pages and flows

Supporting Documentation

Is your feature request related to a problem?

We need to replace smee as this has been deprecated by GitHub and better alternatives exist out there.

Describe the solution you'd like

Investigate what other solutions exist out there and replace all instances of smee with it

Describe alternatives you've considered

No response

Additional context

No response

As discussed in #71 it makes sense to create a mirror with actions disabled (this will come with its own caveats but we can cross that bridge when we get there 🌉)

This will be an option that will be off be default in the creation dialog

Let’s also add an env variable that can force this option to be always on, always off, or toggle-able