This past Sunday I did a livestream where I tried out the new issue forks functionality on Drupal.org. The feature is currently beta and project maintainers need to opt-in for the functionality. At the moment you can create a repository fork for an issue, create a work branch, and commit to that branch. You will need to manually create a patch to be uploaded, as Merge Requests with Drupal.org issues are still being worked on (the Drupal Association Infrastructure team is hoping to have this available for DrupalCon Global!)
When you view an issue that supports issue forks, there will be a new block in the sidebar. This allows you to create an issue fork or view information about the existing fork and its branches.
To work on an issue fork you need to grab the Git URL information and add it as a remote repository to your existing local repository – or you can just clone it directly!
One thing I wish it provided was the full Git command to add as a remote or clone. Everyone should have an SSH key with their Drupal.org account, so I think they could exclude the HTTPS Git remote URL field for the command field.
I had to run the following command to get the issue fork locally and contribute to it
git remote add commerce-3150917 [email protected]:issue/commerce-3150917.git
Another gotcha is that creating an issue fork does not automatically create a working branch for the issue fork. In the case of one issue, a contributor committed directly on the canonical 8.x-2.x branch. Technically you should always create pull request or merge requests off feature branches. So, having it default to a custom branch would be great.
NOTE! If you get a 404 response, make sure you are logged into the Drupal.org GitLab instance. All you have to do is click Sign in and it will perform a single sign on process. This is documented in https://www.drupal.org/project/drupalorg/issues/3155441.
If not automatically, then maybe a better default when creating a branch. When you click the New branch link it launches a prefilled form to open a new branch
The example link gives you the following form:
There's an open issue for supporting new branches on issue fork creation: https://www.drupal.org/project/drupalorg/issues/3155690
Creating a patch without using my local environment!
With the issue fork functionality I was able to create an issue fork and working branch. I used the GitLab Web IDE to modify the selected files. I then using the
.patch URL of my commit to generate a patch to upload to the issue on Drupal.org.
That's pretty cool! This is the kind of things which would have helped speed up the Drupal 9 porting weekend – folks could have forked issues, made the changes in the GitLab Web IDE and told maintainers "hey, here's the commit!"
The only problem is that merged an issue fork directly into the canonical branch is that it won't match the commit format maintainers commonly use:
git commit -m 'Issue #3150917 by zaporylie, mglaman: Create a MinorUnitsConverter service' --author="zaporylie <[email protected]>"
Hopefully we can find some way to preserve this formatting when Merge Requests are added.
Things I am looking forward to
Adding activity comments from the issue fork and its commits to Drupal.org issues. I'd love to see commits that occur on the issue fork bubble up into the issue, with direct links to the issue fork. We currently have this whenever a commit occurs on a repository branch that has an issue number in it.
Creating merge requests for merging work from issues forks. I really cannot wait to try this out. I hope it merges as a rebase and squash and preserves the existing issue credits in the commit. We use this data to calculate the amount of contributors to the Drupal Commerce ecosystem.
Using this in a day to day process!
SUPPORT THE DRUPAL ASSOCIATION
Catch the video recording
Want more? Sign up for my weekly newsletter