Developer Tools Initiative - Part 6: Update on Merge Requests

This is the sixth post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

In March of last year the team here at the Drupal Association migrated all of the Git repositories at Drupal.org from bespoke Git hosting to a self-hosted GitLab instance. This was a major milestone in modernizing the developer workflow, immediately providing better search within project codebases, a better code viewer, and direct code editing in the browser for project maintainers.

However, we know that the primary feature the community has been waiting for is merge requests. We're very excited to report that we're now very close to opening up a beta test of merge requests integrated with Drupal.org issues.

Stepping back for a moment, let's remember the ideal contribution flow that we defined when evaluating our Developer tool options: 

• The issue itself should remain a single-threaded conversation for discussing the particular problem to be solved.
• Every issue will be associated with one canonical issue fork(with multiple branches, as needed) which can be collaborated on by any contributor, and merged by a project maintainer.
• Contributors will be able to modify the code in these issue forks by:
  • Checking out the code and committing/pushing changes to the workspace.
  • Inline editing files using GitLab's web interface.
  • Legacy: uploading a patch.
• All types of contribution—whether merge requests or the legacy patch workflow—will continue to trigger DrupalCI testing.
• Issue forks can be rebased (manually or automatically) when needed to resolve conflicts with upstream commits.
• Contributors and project maintainers will be able to comment on individual lines of code.

The foundation for this work is the ability to create these issue forks from an issue on Drupal.org. This involves building an interface from Drupal.org that creates an issue fork in GitLab associated with the Drupal.org issue, and then any Drupal.org user can push to that fork and branches within it. Maintainers may then merge this work from a branch on the issue fork the project.

That foundational work to create the necessary git hooks and access control management is now complete.

The next steps are:

How can you get involved?

If you are a contributed module maintainer, and would like to be a part of the early beta test program for Drupal.org-integrated GitLab merge requests, please indicate your interest by posting a comment to this issue with a list of projects you would like to opt-in.

When will merge requests be available to the community at large?

Creation of issue forks and branches will be available to a limited subset of projects this week, the week of June 14th, 2020. Over the course of the next several weeks we hope to implement the additional UI features that will display relevant information about the issue forks back in the Drupal.org issue, and ultimately allow merge requests themselves.

We hope to have the beta of merge request functionality available to some projects no later than DrupalCon Global, in Mid-July. From there, we'll work through feedback from our beta testers, and work with Drupal core maintainers, to enable issue forks for all projects in the coming months

We hope that you're as excited about this update as we are. It represents a lot of thought on the part of many community contributors, and a lot of work on the part of the Drupal Association staff.

Post-Script - What about DrupalSpoons?

As you read this update, many of you may be wondering how this work fits together with an emerging community initiative called DrupalSpoons. DrupalSpoons is an effort to not only use GitLab for merge requests, code viewing, inline editing, etc… but also to replace Drupal.org issues and DrupalCI with their GitLab equivalents, unifying the developer experience in a single UI.

To be clear, neither we at the Drupal Association, nor the DrupalSpoons initiative are recommending that projects at large begin migrating to the current experimental DrupalSpoons environment. Rather, DrupalSpoons is encouraging experienced maintainers who want to try the workflow as early adopters to try managing their projects on DrupalSpoons. Their goal is that initiative will prove new workflows and ideas that can be brought back into the official community tools on git.drupalcode.org.

The DrupalSpoons contributors have done some helpful and innovative work so far. We appreciate seeing contributors pushing the boundaries of what can be done with 'off-the-shelf' tools, and there's potentially quite a lot we might learn from this work that will inform future tooling for the Drupal project. For example, it's likely that we'll look to DrupalSpoons' use of GitLabCI as we look towards the next generation of DrupalCI.

We are always watching and listening to see what the community wants and needs for Developer Tools. Over time, new tools emerge that add significant value. As the Drupal Association, being responsible for maintaining these tools, we would like to approach each component independently (i.e: look at merge requests, issues, or GitLabCI, each independently) as the DrupalSpoons project continues.

In the meantime, we are moving forward with integrating GitLab merge requests with the Drupal.org issue queues. Once that's complete, we'd like to see a gap analysis to see what would be gained and lost when comparing Drupal.org issues with GitLab issues.