github-community-projects / internal-contribution-forks Goto Github PK
View Code? Open in Web Editor NEWA GitHub App that allows you to contribute upstream using a "private fork"
License: MIT License
A GitHub App that allows you to contribute upstream using a "private fork"
License: MIT License
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
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.
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
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.
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.
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
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.
This is an issue for supporting GHES with ICF (if even possible).
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.
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"}]}
We need to use the old behavior of branch protections when this error occurs
No response
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.
We need to replace smee as this has been deprecated by GitHub and better alternatives exist out there.
Investigate what other solutions exist out there and replace all instances of smee with it
No response
No response
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.
Support temporary private forks for resolving a security vulnerability within Internal Contribution Forks, if possible.
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.
No response
No response
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
No response
No response
We updated to Probot 13 and this broke payload verification
Send any github payload to the app
Payload shouldn't be parsed before being verified
We need to disable body parsing for the webhook endpoint
No response
No response
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.
Role & Responsibility | Username |
---|---|
DRI | @ajhenry |
Engineering | @sutterj |
github/safe-settings
and see what it would take to integrateWe 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.
Role & Responsibility | Username |
---|---|
DRI | @ajhenry |
Engineering | @sutterj |
### 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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.