Blog Contributing to GitLab after move to a single codebase
October 2, 2019
3 min read

Contributing to GitLab after move to a single codebase

How contributors can benefit from the move to a single codebase for GitLab Community and Enterprise Editions.

2018-09-13-gitlab-hackathon-cover.jpg

By now, many readers will already be familair with GitLab's move to a single Rails codebase for GitLab Community(CE) and Enterprise(EE) Editions. The motivation for the change and work involved were well documented in blog posts by Marin Jankovski and Yorick Peterse. Also, if you had an open merge request (MR) in CE, you probably saw messages from the GitLab bot (@gitlab-bot) like the one below.

GitLab bot message

Only impacts contributions to the new GitLab repository

I want to highlight a couple of things with this move to a single codebase. First, if you are contributing to other GitLab projects such as Charts, GitLab Design System, GitLab UI, Omnibus, Runner, etc., this move to a single Rails codebase for CE & EE will not have any impact on your contribution workflow.

Licenses remain the same

Next, there is no change to licensing. GitLab CE will remain open source under the MIT license. GitLab EE code will reside in the ee directory in the new gitlab (formerly gitlab-ee) project and will remain source available under a proprietary license.

Higher efficiency and easier to contribute

With this move to a single codebase, there will be less duplicate work and manual intervention required from GitLab team members in the future. This gives them more bandwidth for higher value activities, including helping with wider community contributions.

The single codebase should also simplify things for wider community members, as you can now search for issues in one place, and there's also one place for MRs.

As another example for improvement, in the past, contributors occasionally had to deal with ee_compat_check errors when they submitted an MR in CE. This required opening an MR in EE (or asking a GitLab team member to open an EE MR) and then wait for it to be merged before continuing with the CE MR. This was a pain point for many contributors, and I am excited that this will be eliminated with the single codebase.

Re-submitting MRs against the new GitLab project

If you have an MR that was auto-closed by the GitLab bot in CE (now GitLab FOSS), you can continue your work by creating a new MR in the new gitlab project following the steps outlined in the GitLab bot message above. If you have any questions or encounter issues when you open a new MR, please feel free to mention the reviewers from your original MR or me and ask for help.

During and after the transition, I was happy to see MR's continuing to come in from the wider community so it doesn't look like this was a major disruption. However, if you have any questions or feedback you are welcome to open an issue in gitlab or reach out to me at [email protected].

"GitLab application screengrab" by Pankaj Patel on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert