Study - investigate "internal-contribution-forks"

[maoo]

@JamieSlome @coopernetes - we got notified by Github about this project, internal-contribution-forks, whose mission is to allow you to contribute upstream using a 'private fork'

Before I share my thoughts on this, I'd like to hear yours, specifically:

• how does this approach diverge from Git Proxy
• why/how (or why not) the 2 approaches can be merged/integrated
• if it's worth mentioning this approach on Git Proxy readme, remarking similarities and differences

[JamieSlome]

Hi @maoo.

I've had a run through session with @ashleywolf, @pholleran and @ajhenry fairly recently. Catching up with @ahpook to discuss and think about some integration/collaboration points between the solutions.

1. The approach diverges in that you contribute to some private upstream repository directly, where assessment of the code, compliance checks occur before (automatically?) publishing the code via GitHub specific API flows to a public repository, post some PR merge. With Git Proxy, it supports assessment and review of the code internally prior to leaving the company organisation (i.e. policies configured and assessed on company network, vs. configured and assessed on public GitHub.com).

2. From my perspective and what I understand, this approach is suited for all organisations that are happy pushing code to public GitHub (private repositories), and then running policy and compliance checks via GitHub Actions on GitHub.com (still in a private repository). I believe the solution is deployable too, so likely meets the requirement of being able to run compliance and audit checks internally (I think?). In terms of possible integration and collaboration, it requires a little bit more thought and hashing out from my side.

3. It would be first good to pull together a feature matrix to actually understand the core differences.

@ashleywolf @pholleran @ajhenry @ahpook - feel free to correct me on anything; just taken my best stab here! 👍

[ahpook]

From my perspective and what I understand, this approach is suited for all organisations that are happy pushing code to public GitHub (private repositories), and then running policy and compliance checks via GitHub Actions on GitHub.com (still in a private repository). I believe the solution is deployable too, so likely meets the requirement of being able to run compliance and audit checks internally (I think?). In terms of possible integration and collaboration, it requires a little bit more thought and hashing out from my side.

This is largely correct @JamieSlome - though I'd amend the first part to say you can push to GitHub Enterprise Cloud organisations, which are more tightly separated than private repos on github.com are. And yes, it is suitable to run on any docker environment that can talk to GHEC, so it could run inside the perimeter.

[coopernetes]

This project doesn't really address compliant open source development for air-gapped environments. Git Proxy's usefulness is directly correlated with your organization's risk tolerance to having development happen outside a corporate network. We are a GHES shop and need both our compliance checks being applied with code leaving our network as well as the need for internal (private) development, code review & scanning.

That said, we have implemented a very similar repo mirroring & syncing process which ICF also solves. I still believe there is a need for a network-based control point through Git Proxy but these two projects are very complementary.

One last thing to note - we're building a very similar UI for setting up internal contribution via Backstage. I'll be taking a look at ICF as an alternative backend that we could integrate with on our internal platform. It's likely more robust than our existing process for accomplishing the same thing.

Excited to hear more from the GitHub OSPO team in this space 👍

[JamieSlome]

Closing comments 💬

@coopernetes @maoo - we can probably close off this issue. I've had a productive set of sessions with Andrew (@ajhenry) and Eric (@ahpook).

There is a clean overlap of interests here around plugins (checks and balances on pushed code). I've invited Andrew to our fortnightly call so we can touch base and crack on with plugin development (this can occur asynchronously). I'd like us to think about how we can structure this and whether we run this as a separate "plugins" working group.

@ahpook @ajhenry - let me know if I've reflected our discussion correctly or if any extra comments required.

Vision 🔮

The below does not reflect specific plugin functionalities but rather the potential consumption and collaboration model between us, GitHub and other VCS providers. Again, any reflections and tweaks are appreciated.

[maoo]

@ajhenry and @ahpook - could you please ping me on help@finos.org , so I can add you to the meeting invite?

Thanks @JamieSlome for sharing!

[JamieSlome]

Closing this issue for now as we have nicely cross-pollinated 🐝 with the GitHub team and have identified a good starting point for collaboration on ICF and Git Proxy.