An automated and manual process, where GitLab Continuous Integration (CI) and Maintainers join forces to keep harmful code from entering its realm and accidentally pushing out proprietary or sensitive code.  

This process opens enterprises to leverage the open-source community on core capabilities which would otherwise require a rigorous and belabored hiring process that can make some internal projects non-starters. 

Background 

We recently d ArQ and are accepting contributions to both our public and our internal repositories. Maintaining an  repository and keeping it in sync with an internal one required us to design and implement a bidirectional syncing solution. Read about our solution here. 

TL;DR: Bidirectional Sync Solution 

ArQ's public-production internal branch is the staging ground where reviewed and approved code ends up before crossing the threshold into the open or closed realm.  

On every push a developer makes to their internal unprotected branch, which happens at a high frequency, our GitLab CI runs a job that merges the open-source production branch code into our internal public-production branch.  

Every time we merge code from the internal production to public-production, a manual job is made available to push the internal code out to GitLab public. 

What is code gatekeeping? 

Code gatekeeping is when code maintainers manually review and approve the code that enters and leaves internal software through continuous Merge Requests. We created a GitLab CI job that POSTs to the GitLab API to generate Merge Requests when either the public-production  or production branches are updated. Auto generating merge requests when code is updated frees up Maintainers' workload to concentrate on the more important task of writing and reviewing code. 

GitLab CI 

The public-production-auto-merge-request job requires a personal access token with API scope to POST to GitLab API. To run the job successfully, we install curl and configure the job to only run when the public-production and production branches are updated. The automerge-request shell script is executed when these conditions are met. 

In this script, if no Merge Requests from public-production or production are found, then the following POST request to create a merge request is sent. 

Conclusion

Keeping two repositories in sync requires continuous pushing and fetching of code and continuous reviewing and approving the movement of code. Auto generating merge requests when code is updated frees up Maintainers' workload to concentrate on more important tasks. Shout out to Riccardo Padovani and Gitlab's Blog Platform for the guidance in automating this task.