Issue Forks and Merge Requests are scheduled for general availability on all projects on Nov 10, 2020.
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:
- Exposing the UI for issue forks and branches on Drupal.org issues.
- Deciding what information to display about activity on issue forks and branches.
- Enabling users to open merge requests from their issue forks and branches.
- Deciding what activity to post back as comments to the issue queue (i.e: merge request open, new activity on merge request, merger request closed, etc).
When will merge requests be available to the community at large?
Creation of issue forks is now available to a limited subset of projects this week. 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
How can you get involved?
As a module maintainer, please leave a comment on this issue with the list of your project shortnames that you'd like to opt-in.
Please note that not all projects will necessarily be selected for the beta trial.
Comment | File | Size | Author |
---|---|---|---|
#104 | DO_Forks_Patch_file_from_Gitlab_merge_request.png | 176.16 KB | bserem |
#104 | DO_Forks_Patch_file_from_Gitlab.png | 131.23 KB | bserem |
Issue fork drupalorg-3152637
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
hestenetComment #3
singularoHappy to beta/trial on:
stratoserp
shepherd
Comment #4
jonathanshawVery happy to beta on xero_sync. Surprised not more replies here, I'm really looking forward to using this as a contributor.
Comment #5
mglamanIt'd be great to try with Drupal Commerce.
Comment #6
dwwNot that there's much dev traffic, but I'd be happy to give this a spin at least at:
https://www.drupal.org/project/views_taxonomy_term_name_into_id
I'm asking co-maintainers about a few others actually in use (address, datetime_extras, etc) and will reply here once there's confirmation.
You could do these, too, but seriously no one uses them but me (from what I can see):
https://www.drupal.org/project/entity_reference_number_widget
https://www.drupal.org/project/toolbar_responsive_search
;)
Excited to see this coming together!
Thanks!
-Derek
Comment #7
benjifisherI maintain a few small projects:
Comment #8
markie CreditAttribution: markie at Mediacurrent commentedBeta trial on smart_trim please.
Comment #9
DamienMcKennaA *huge* thank you to everyone who has worked on this effort, it's greatly appreciated!
I'd be happy to test this on the Metatag project.
Comment #10
bobbygryzyngerThanks all! I would be happy to test this on shopify.
Comment #11
NickDickinsonWildeI'd love to opt in for EVERYTHING, but reasonably:
- views_slideshow
- field_states_ui
- entity_redirect
Comment #12
zoiosilva CreditAttribution: zoiosilva as a volunteer and at Taoti Creative commentedVery interesting, seems to be the right way to go. I wonder if it would be possible to point to "fork versions" of the module using composer.
Comment #13
Greg Boggseasy_breadcrumb
config_suite
styleguide
author_pane
alinks
Comment #14
drummThis won’t be possible. Packages.drupal.org only has metadata for releases made by maintainers. And there’s a chance you’ll want to combine changes from multiple issues, so no single fork will have everything you need for deployment.
I recommend still using https://packagist.org/packages/cweagans/composer-patches. If the changes you want from an issue are in a single commit, you can get the plain diff from GitLab like https://git.drupalcode.org/issue/drupalorg-3071681/-/commit/5e4cc03e8b3c.... GitLab does not support arbitrary diffs yet: https://gitlab.com/gitlab-org/gitlab/-/issues/15593. So for changes with more commits, you’ll need to make and store the diff locally. That isn’t a bad idea overall, less reliance on 3rd parties for builds is always nice.
Maintaining your own local fork of the repository for deployment, combining changes from multiple issue forks, is also possible.
Comment #15
drummstratoserp, shepherd, xero_sync, commerce, views_taxonomy_term_name_into_id, entity_reference_number_widget, toolbar_responsive_search, typogrify, ptoc, multicolumn, smart_trim, metatag, shopify, views_slideshow, field_states_ui, entity_redirect, easy_breadcrumb, config_suite, styleguide, author_pane, alinks are all now opted in. Please follow up here if I managed to miss any, or if there are more to add.
I’ve done an initial pass at the documentation at https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer..., which is linked from the bottom of each Issue fork block. In particular, you may need to nudge contributors to still post patches to the issue queue for DrupalCI testing until #3072048: Test merge requests made in GitLab with DrupalCI is done.
Any followups on the functionality will be best at #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces, or one of its child issues. Ideas for merge requests can go to #2205815: Merge requests in Drupal.org issue queues?.
Comment #16
drumm(Minor update to issue summary)
Comment #17
alexmoreno CreditAttribution: alexmoreno commentedHappy to beta test it in webp as well
Thanks, exciting times 😊
Comment #18
drummwebp has them now too.
Comment #19
dwwThanks, @drumm, this is very exciting!
I got confirmation for both of these, too:
Cheers,
-Derek
Comment #20
drummaddress & datetime_extras are done!
Comment #21
ChristianAdamski CreditAttribution: ChristianAdamski commentedI'd like to take part in the beta as well with
Geolocation module
Thanks!
Comment #22
drummAdded geolocation too
Comment #23
mahmoud-zayed CreditAttribution: mahmoud-zayed as a volunteer and at ImageX for ImageX commentedHappy to beta test it on bootstrap_layout_builder
Comment #24
mglamanRequesting commerce_api as well, as we're actively developing there
Comment #25
drummIssue forks have been added to bootstrap_layout_builder & commerce_api
Comment #26
nicoloye CreditAttribution: nicoloye as a volunteer commentedHello, happy to beta test it on forms_steps.
Thanks !
Comment #27
andypostMasquerade module already trying to use issue branch, so requesting testing here
Comment #28
drummforms_steps & masquerade can now use issue forks.
Issue forks have their basic functionality working now, and we’re officially moving into working to enable merge requests: #2205815: Merge requests in Drupal.org issue queues?
Comment #29
andypost@drumm Thank you!
Now it looks like old branches are not compatible with new forks or the old "workspaces" block could be removed
Example in right sidebar https://www.drupal.org/project/masquerade/issues/2923845
Comment #30
volegerI also can try to test new fork flow on toolbar_language_switcher module
Comment #31
ressa CreditAttribution: ressa at Ardea commentedGreat news! I heard about it via @mglaman's blog post Trying out issue forks on Drupal.org!, and it looks like the initiative wasn't announced on Planet Drupal. Perhaps intentionally, since it is in Beta? Otherwise, announcing it on Drupal Planet would probably increase the number of participants, if that is desired.
Also, perhaps consider updating "Pull/merge request" in the graphics to "Merge request", since that is what Gitlab use, and also what is used in the text on this page?
Comment #32
hestenetHm! The post definitely went out on the Drupal.org blog- https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-6-...
Are we sure that didn't make it to Planet?
Comment #33
djdevinHappy to test on https://www.drupal.org/project/quiz
Comment #34
ressa CreditAttribution: ressa at Ardea commentedSorry, you're right @hestenet, it's on page 2 of Drupal Planet ("Developer Tools Initiative - Part 6: Update on Merge Requests" 17 Jun 2020 at 21:03), with a link to this issue. I was looking for the title of this page, which is of course an issue, and not a blog post :-)
Comment #35
drummtoolbar_language_switcher & quiz now have issue forks!
That block has branches made in the project repository, which might differ from the issue fork. People working in the issue fork might want to use those branches in the issue fork, and they are still useful to know about. As a maintainer of a project, using feature branches without merge requests might remain as a useful part of some workflows.
Comment #36
jurgenhaasI'd like to opt-in with
Comment #37
volegerthat would be nice to have an option to generate the full git command with remote URL and proper remote name.
Fewer interactions with sidebar would be better for newcomers and will save few seconds in general.
Now I have to copy remote-name and remote URL separately (one interaction to expand the Clone block and 2 copy interaction).
I also noticed that now a maintainer would work more with different remotes on the single project, so I propose adding a recommendation to rename "origin" remote name to "< project_name >" remote name. This will reduce possible unintended pushes to the wrong repo during the work on multiple projects.
Comment #38
drummI opened #3155137: Add full Git commands for working with issue forks to follow up on adding instructions. I’ve made an initial pass at documenting best practices at https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer.... They could use additional work and real-world use before adding them to the UI.
Comment #39
drummcolorbox_field_formatter, config_auto_export, dimension & wysiwyg_template now have issue forks enabled.
Comment #40
hussainwebI'll be very happy to test this on these two projects:
- https://www.drupal.org/project/do_username
- https://www.drupal.org/project/wordpress_db_migrate
Comment #41
johnzzonWe'd be extremely happy to test this on https://www.drupal.org/project/layout_builder_modal
Comment #42
opdaviesRequesting for Override Node Options, Copyright Block module, Tailwind CSS Starter Kit, Null User and System User.
Comment #43
drummdo_username, wordpress_db_migrate, layout_builder_modal, override_node_options, copyright_block, tailwindcss, null_user, system_user all now have issue forks enabled, thanks!
Comment #44
opdaviesThanks Neil.
Comment #45
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedI'd like to try this on
migrate_devel
module, please. There's an issue there which I'm considering a few different approaches for, so the multiple branch aspect of issue forks will be interesting to try.Comment #46
hussainwebThank you @drumm!
With a very basic trial, I see two things.
1. Give commands we can copy/paste to pull the changes as a branch in the repo. I see you have already created an issue for this at #3155137: Add full Git commands for working with issue forks.
2. Clarify the reason and usage for "New branch".
Right now, this appears immediately once we click "Fork [project]". It kinda implies that we should click that to create a new branch. My first thought is why even have this option. In most cases, we have a patch build upon a previous patch, so a single branch should be enough. That said, there are some reasons for having multiple branches:
1. Rebasing, but even merging the main branch into the issue fork branch would give similar results.
2. Trying out an entirely different approach.
Now, the second point is not frequent but still a valid reason to have this functionality. I would suggest we could improve the UX around this to clarify how maintainers could use the feature. How about something like this?
1. When someone clicks "Fork [project]", a fork for the issue is created along with a separate branch. The branch name could be the same as the issue number. It could (optionally) be prefixed or suffixed with the issue branch so that the maintainer knows the target branch from the branch name.
2. The "New branch" option should still be there but in most cases, we never have to use it.
3. Give per-branch commands that the contributors can copy/paste to pull in changes for each of the branches.
Another thing I'm wondering: Do these issue forks get cleaned up once the issue is closed or at some other point?
Comment #47
ressa CreditAttribution: ressa at Ardea commentedPS. I still think the graphic could benefit by getting updated from "Pull/merge request" to "Merge request", since that is what Gitlab use.
Comment #48
Bhanu951 CreditAttribution: Bhanu951 as a volunteer commentedI would like to try it on my sandbox project.
Please enable access to it.
https://www.drupal.org/sandbox/bhanu951/3103712
Comment #49
drummmigrate_devel & sandbox/bhanu951/3103712 are now opted in.
Opened #3155690: Add new branch on issue fork creation for this.
There will be a lot of information in intermediate commits, comments on those, comments on the merge request, etc, that could be useful for digging into followup issues. And while non-ideal, patches do get deployed to production sites, we don’t want to break everyone’s builds right away.
The issue fork itself is relatively cheap, GitLab doesn’t make a full copy of the project repository’s history. Other data will pile up, and potentially become large or cumbersome, we’ll have to wait and see how it behaves under real use. Removing issue forks for closed (fixed) issues after some number of weeks or months is likely in the long run.
Comment #50
smccabe CreditAttribution: smccabe at Acro Commerce commentedcommerce_fraud plz
Comment #51
volegerAlso noticed that would be helpful to have two links on the commit comment message:
- first is the link to the diff on Gitlab UI between commit and source repo branch; No glue for now how to generate the link to the diff without merge requests enabled.
- another link available if it's not the first commit. This link will follow the user to the diff page between the commit and previous commit within the forked repo.
https://git.drupalcode.org/issue/{fork_id}/-/compare/{previous_commit_hash}...{commit_hash}
So in the result the commit comment message would be provided automatically with two diffs
- first diff will show the compatibility with upstream branch, and it woul be actual patch if no conflicts would be provided. So that patch can be downloaded from the Gitlab UI and uploaded to the issue be page for the testing purposes.
- second - classic interdiff between the
patchescommitsComment #52
dpiRequesting for preview_link since there is active development.
Comment #53
drummcommerce_fraud & preview_link are now opted in.
voleger - I noted your comment at #3071681: Decide what information about issue forks to show on issue page on Drupal.org, implement.
For now, I’m concentrating on enabling merge requests and fixing any bugs, then I’ll come back and do another pass at the UI.
Comment #54
kristiaanvandeneyndeHell yeah, sign me up! Group and Subgroup please.
Comment #55
drummgroup & subgroup now have issue forks enabled.
Comment #56
jsacksick CreditAttribution: jsacksick at Centarro commentedHey, could you opt in commerce_paypal and commerce_shipping please?
Comment #57
plopescCould be possible to have it enabled in https://www.drupal.org/project/migrate_default_content?
Thank you
Comment #58
drummcommerce_paypal, commerce_shipping & migrate_default_content now have issue forks enabled.
Comment #59
drumm#3071755: Show merge request activity on www.drupal.org issues & #3071752: Enable ability to open merge requests for branches in issue forks are going well. We should be able to do initial enabling of merge requests for the beta projects as soon as tomorrow. I’m planning to update those issues with details, and open followup issues to track a few backlogged items, before enabling them.
Comment #60
drummMerge requests are now enabled for the beta projects. Notably, DrupalCI testing is still in our backlog: #3072048: Test merge requests made in GitLab with DrupalCI
Other feedback around merge requests, and the rest of our backlog is at #2205815: Merge requests in Drupal.org issue queues? & #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces
Comment #61
mandclu CreditAttribution: mandclu at Northern Commerce commentedWould love to try this for my projects, especially smart_date
Comment #62
hussainwebCan I also ask to enable this on my new project: preloader? I am working on that at the moment and could test the functionality there.
Comment #63
tedbowExciting!
I would like to opt-in on https://www.drupal.org/project/role_notices
Thanks!
Comment #64
nkoporecWould love to try it out on: https://www.drupal.org/project/sitemeta
Thanks!
Comment #65
energee CreditAttribution: energee as a volunteer and at EPAM Systems commentedSign me up: https://www.drupal.org/project/adminimal_admin_toolbar
Comment #66
sanduhrsOpt-in for
https://www.drupal.org/project/rdfui and
https://www.drupal.org/project/openid_connect/
please.
Thank you!
Comment #67
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer and at QED42 for Drupal India Association commentedThis is amazing!
I'd love to Opt-in for:
Thank you!
Comment #68
drummsmart_date, preloader, role_notices, sitemeta, adminimal_admin_toolbar, rdfui, openid_connect, asymmetric_menu_trees, flexible_add_more_widgets & media_thumbnail_url_formatter all now have issue forks enabled. Thanks for testing out this new functionality.
Comment #69
volegerNoticed that there is no possibility to change the issue status from the related merge request page.
Is it possible to synchronize the merge request label's definitions with the related issue field values?
Let's say, I had reviewed proposed changes and wanna change the issue status to RTBC, so I can just set the appropriate label in the merge request page, and in the result related issue has updated issue status.
Comment #70
volegerI want to opt-in for the following projects:
https://www.drupal.org/project/bbb
https://www.drupal.org/project/filefield_paths
https://www.drupal.org/project/upgrade_check
https://www.drupal.org/project/email_nd
https://www.drupal.org/project/menu_item_extras
https://www.drupal.org/project/taxonomy_access_fix
Thank you!
Comment #71
saschaeggiI'd like to opt-in for the following projects:
https://www.drupal.org/project/gin
https://www.drupal.org/project/gin_toolbar
https://www.drupal.org/project/gin_login
https://www.drupal.org/project/graphql_twig
https://www.drupal.org/project/graphql_responsive_image
https://www.drupal.org/project/paragraphs_modal_edit
Thanks a lot!
Comment #72
scuba_flyI would like to opt-in the following projects:
cocoon_media
elui
social_media
Comment #73
fabianderijkWould be happy to help testing with the following projects:
https://www.drupal.org/project/fortytwo
https://www.drupal.org/project/flood_unblock
https://www.drupal.org/project/rest_menu_items
https://www.drupal.org/project/o365
Comment #74
yannickooI would like to opt-in for following modules:
Thanks! :)
Comment #75
drummIssue forks are now enabled for bbb, filefield_paths, upgrade_check, email_nd, menu_item_extras, taxonomy_access_fix, gin, gin_toolbar, gin_login, graphql_twig, graphql_responsive_image, paragraphs_modal_edit, fortytwo, flood_unblock, rest_menu_items, o365, linked_field, menu_link_attributes, view_mode_selector, social_media, elui, cocoon_media
Yes, we’ll need to figure this out. Another consideration is which merge request is the agreed upon solution for the issue. With patches, the best patch is occasionally not the most-recently-uploaded, and people end up re-uploading it again just to make that the latest patch. We don’t want to repeat that.
Comment #76
DamienMcKennaSomething I noticed: while comments on merge requests are posted back to the issue, they are not delivered via email to the issue's followers. That said, it does send a message when a new pull request is created, so it's a step forwards. I'll open a new issue about this.
Comment #77
wizonesolutionsI would like to opt in for:
fillpdf
commerce_recurring_metered
commerce_recurring_pcui
Comment #78
WidgetsBurritos CreditAttribution: WidgetsBurritos at Rackspace commentedI would like to opt in these two modules:
Comment #79
drummweb_page_archive, performance_budget, commerce_recurring_pcui, commerce_recurring_metered & fillpdf now have merge requests enabled.
Comment #80
Kgaut CreditAttribution: Kgaut commentedI'd like to optin also for this module :
apidae_tourisme
Comment #81
drummapidae_tourisme now has issue forks enabled.
Comment #82
matthieuscarset CreditAttribution: matthieuscarset as a volunteer and commentedI'd like to opt in for these modules please:
Comment #83
codekarate CreditAttribution: codekarate commentedI'd like to optin for the gatsby module please.
Comment #84
drummmenu_manipulator, menu_manipulator_sitemap, twitter_api_block, block_user_info, and gatsby now have issue forks enabled.
Comment #85
grahlPlease enable it for crm_core, ldap, ldap_sso and rokka. Thanks!
Comment #86
drummIssue forks are now enabled for crm_core, ldap, ldap_sso & rokka
Comment #87
tunicWe would like to opt in for the GA Push module, please.
Thanks!
Comment #88
drummIssue forks are now enabled for ga_push!
Comment #89
bserem CreditAttribution: bserem at zehnplus commentedI'd like to opt in for (in order of preference):
https://www.drupal.org/project/pace
https://www.drupal.org/project/admin_feedback
https://www.drupal.org/project/rua (only for Greek sites)
https://www.drupal.org/project/commerce_winbank_redirect (only for Greek sites)
Thanks :)
Comment #90
drummIssue forks are now enabled for project_issue_file_test, pace, admin_feedback, rua & commerce_winbank_redirect
Comment #91
bserem CreditAttribution: bserem at zehnplus commentedGreat, thanks!
Comment #92
brianperryI'd be interested in opting in for ui_patterns_pattern_lab. Thanks!
Comment #93
drummui_patterns_pattern_lab now has issue forks enabled.
Comment #94
mglamanWould 💙 to add this to commerce_avatax
Comment #95
drummcommerce_avatax now has issue forks enabled.
Comment #96
alisonHi! Would love to opt-in "nodeaccess", please!
Thank you so much!
Comment #97
nod_Could you add the pwa module please?
Comment #98
Balu ErtlI’d love to help this workflow integration efforts by reporting feedback with my following contrib modules:
config_partial_export
config_single_export
l10n_tm
l10n_terminology_long
l10n_terminology_short
Comment #99
drummconfig_partial_export, config_single_export, l10n_tm, l10n_terminology_long, l10n_terminology_short, pwa & nodeaccess now have issue forks enabled.
Comment #100
GrimreaperHello,
Could you please add the following modules?
- Context Profile Role
- File Extractor
- Image Styles Mapping
- CMIS API
- Entity Share
- Entity Share Cron
- Entity Visibility Preview
Regards,
Comment #102
drummcontext_profile_role, file_extractor, mage_styles_mapping, cmis, entity_share, entity_share_cron, and entity_visibility_preview now have issue forks enabled.
For core, we are going to beta test with a small number of individual issues to make sure everything is working. The first issue is #3151676: Remove unnecessary calls to drupal_get_path(), replace with __DIR__
Comment #103
renatogPlease can you add it on Modal Page?
https://www.drupal.org/project/modal_page
Thanks a lot
Comment #104
bserem CreditAttribution: bserem at zehnplus commentedWe've been testing FORKS and MRs in my team (the first impressions are really good) and I'd like to point out something that might not be clear to everybody:
Gitlab does generate a Patch file for one commit, which is easily accessible with a URL (that can be added to Composer for example):
The same is true for a merge request, just a bit harder to find a first:
Luckily enough it seems that the patch filename doesn't change when the MR gets more commits, but the contents do. So people will always get the updated version in their composer patches using the same URL to the patchfile (which could also lead to other issues!).
@drumm Should we document this in the top of this issue or shall I add it to the docs page here: https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...
Comment #105
Grimreaper@drumm, Thank you :)
Comment #106
drummmodal_page now has issue forks enabled.
bserem - Please go ahead and edit https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer..., thanks! This issue summary is effectively temporary and won’t be updated once issue forks are enabled for all projects.
Comment #107
bserem CreditAttribution: bserem at zehnplus commentedDone, here is the link with instructions on getting patch files from Gitlab to be used with Composer (or other tool):
https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...
Comment #108
a-fro CreditAttribution: a-fro commentedWe'd be happy to test with recent modules we've been working on:
https://www.drupal.org/project/collection
https://www.drupal.org/project/erf
Comment #109
drummcollection & erf now have issue forks enabled.
Comment #110
AaronBaumanJust came to this thread after seeing merge requests had been enabled on gitlab - exciting!
Please opt-in to issue forks for https://www.drupal.org/project/salesforce
thanks drumm!
Comment #111
drummsalesforce now has issue forks enabled.
Comment #112
mattshoafI'd like to sign up for the beta: webform_myemma
Thanks!
Comment #113
markie CreditAttribution: markie commented+1 on adding how to get a patch URL for composer out of a merge request / commit to the documentation / issue description. That was a great find.
Comment #114
krlucas CreditAttribution: krlucas commentedPlease enable Google Analytics Event Tracker for issue forks:
https://www.drupal.org/project/google_analytics_et
Comment #115
jwilson3Probably the wrong thread to discuss this, but tbh not sure of a better place to comment this, that would get eyeballs:
Isn't this inherently a bit reckless? Most people use cweagans/composer-patches these days to link to a patch from Drupal.org If the patchfile gets updated magically, then each time a build tool builds a deployable artifact, you could be deploying unvetted code. (Eg, Imagine someone accidentally committing a syntax error to a patch -- an unfortunately timed release could cause an unpredictable 500 error causing at the worst a production site downtime, and at the least a developer scratching their head scrambling to track down and back out something potentially completely unrelated to the intentional code changes in the release that broke unexpectedly).
Comment #116
AaronBaumanYes, most users probably don't want to run with MR-patches from gitlab.
commit-patches are fine, since they will not change.
If you need patches from more than one commit, either upload the patch to the issue or add it directly to your project, per
Drumm's suggestion in #14:
Comment #117
drummgoogle_analytics_et now has issue forks enabled.
Comment #118
volegerI would like to opt-in the following projects:
- pmfs
- queue_ui
Thank you!
Comment #119
drummIssue forks are now enabled for pmfs & queue_ui.
Comment #120
fgmIs it possible to have issue forks enabled for "dfp" ? I'm a not the maintainer of the module, but there's a pending D9 port issue which has been RTBC for months and having a fork would enable sites to reference the fork until the maintainers commit the D9 version to the mainline.Retracted: @Gábor Hojtsy suggested a better approach, using branch aliases.
Comment #121
volegerI would like to opt-in the following issues:
#2124069: Convert schema.inc to the update.update_hook_registry service (UpdateHookRegistry)
#697946: Properly deprecate module_load_include() and move it into \Drupal::moduleHandler() service
#3014752: Convert drupal_rebuild() and drupal_flush_all_caches() functions into cache Rebuilder class
#3038513: Move drupal_generate_test_ua() into the test system
hope that will help to move things forward.
Thanks!
Comment #122
drummIssue forks are now enabled for those core issues. #3167029: Opt-in core issues into the Drupal.org Issue Forks and Merge Requests Beta is the main issue for opting in core issues.
Comment #123
Gábor Hojtsy@fgm: Matthew Grasmick (my boss) who originally documented his use of composer version aliases (at https://matthewgrasmick.com/posts/screencast-updating-drupal-9-15-minutes) told me yesterday he does not suggest those anymore, given that tricking composer to thinking Drupal 9 is Drupal 8 could cause other issues. He also said issue forks would indeed be the best intermediate solution for now until a project lands their Drupal 9 patch. That is not widely possible at the moment due to the feature being in the testing phase.
Comment #124
fgm@Gábor Hojtsy thanks for the heads up. For now, this solved our issue, but I'll keep an eye on this issue to switch to issue forks when they become available for those lagging modules the maintainers don't update.
Comment #125
MixologicIssue forks do not show up at packages.drupal.org, so even if you had one enabled it would not help with the d8->d9 situation.
Comment #126
DamienMcKenna.. but you could use git to download the fork..
Comment #127
Gábor Hojtsy@Mixologic yeah it would be more like what @DamienMcKenna suggests, the "Require Any Git Repository with Composer" section from https://www.daggerhart.com/composer-how-to-use-git-repositories/ let's say, where you specify the metadata for composer and pull in the git repo. The git repo for the fork would mean there is a canonical repo for the Drupal 9 port in progress and no need to fork it on github, etc. Maybe at that point https://github.com/cweagans/composer-patches would work to patch the repo as well locally and thus no need for the fork git repo necessarily? That would be a good discussion for #3168047: Commit Project Update Bot patches to under-maintained projects for Drupal 9 compatibility.
Comment #128
hestenetUpdated issue summary to note that we intend to push issue forks and merge requests to general availability across all projects on November 10th.
You may still request an opt-in to the beta period in the meantime.
Comment #129
hestenetComment #130
hestenetComment #131
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedHi! We're going to undertake a major rewrite of EU Cookie Compliance and start working on a version 2.0. Would be really cool if we can be part of the beta.
Comment #132
drummEU Cookie Compliance now has issue forks enabled.
Comment #133
frobI would like to try this with:
speedboxes
google_analytics_et
google_analytics_lite
Comment #134
drummspeedboxes & google_analytics_lite now have issue forks enabled. google_analytics_et already had issue forks.
Comment #135
batigolixWould be happy to help testing with this project:
- https://www.drupal.org/project/flood_control
Comment #136
fabianderijkWould love to join with the flood_control module!
Comment #137
drummflood_control now has issue forks enabled.
Comment #138
jhodgdonI'd like to opt in with the following projects:
https://www.drupal.org/project/honey [it's a theme project, hope that is OK]
https://www.drupal.org/project/config_update
Thanks!
Also I just updated this docs page:
https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine...
and recently have also made this one:
https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...
The new one is for maintainers; the older one is for all contributors.
Comment #139
drummIssue forks are now enabled for honey & config_update
Comment #140
jrglasgow CreditAttribution: jrglasgow commentedI will opt-in https://www.drupal.org/project/saml_sp
Comment #141
drummIssue forks are now enabled for saml_sp.
Comment #142
mxr576I'd like to opt-in with https://www.drupal.org/project/mjml
Comment #143
drummmjml now has issue forks enabled.
Comment #144
eelkeblokI would like to opt-in with
https://www.drupal.org/project/fragments
https://www.drupal.org/project/drush_lock
Comment #145
drummfragments & drush_lock now have issue forks enabled.
Comment #146
vdsh CreditAttribution: vdsh commentedI would like to opt-in with:
https://www.drupal.org/project/leaflet_geojson
https://www.drupal.org/project/geocluster
https://www.drupal.org/project/libraries_delay_load
Comment #147
drummleaflet_geojson, geocluster & libraries_delay_load now have issue forks enabled.
Comment #148
drummIssue forks are now enabled for all issues. Thanks for testing them out on your projects!
Comment #149
TR CreditAttribution: TR commentedUm, how do I opt OUT of this?
This was rolled out with no notice to contributed project maintainers, without a change record, and with incomplete and outdated documentation (e.g. https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...).
I am not interested in changing the workflow for my projects at this time.
Comment #150
hestenetHi @TR
There is no way to opt out of the feature, however, I will note that the existing patch workflow and all of the testing configuration for patches still work exactly as they always did, at least for now.
If someone makes a merge request on an issue but you'd rather treat it as a patch, you can also still get a plain text diff and work with it that way.
Opening a merge request and using those is only an additional feature on top of these issues.
As far as communication goes:
Yes - you are correct that we did not do an all-maintainer email. I will rectify that today and get one sent out with links to the documentation. We set the date in collaboration with core maintainers, and we did do notification in a few places:
I'll get a notification email for maintainers drafted to be sent directly, with links to the CR and documenation.
Comment #151
hestenetI meant to include documentation links in that last comment. Here they are (from the change record):
And yes! They absolutely do need additional updating - and it would certainly be appreciated if anyone who participated in this beta would help to do so.
Comment #152
TR CreditAttribution: TR commentedChange record was still a *draft* when I posted #149; it was only published after my post, and it was only created yesterday.
By "incomplete and outdated documentation", I gave a specific example where the documentation is still tagged as "incomplete" and the content of that documentation described this feature as not finished - "in active development and being tested with some projects". You have changed some of that content since my post in #149.
Yes, I have been aware of this work in progress for some time, and I deliberately did NOT opt-in when this issue was opened back in June. The communications I've seen all portray this as "opt-in" to allow developers the ability to use this workflow. It's talked about as an *option*. Noticeably absent is discussion about how the larger community will be impacted by this change - sure, a lot of developers will appreciate this feature, but a lot more would appreciate it more if it were optional, because we all have our preferred sets of tools. And the rest of the community (the majority) will look at this as yet another huge impediment towards contribution.
What has not been adequately communicated is that this feature would become mandatory for everyone at some point. While I have no objection to this feature being used where it is wanted, having it forced on us is another matter. There is a larger issue about whether this continued race towards an even more developer-centric Drupal is beneficial to the community. The vast majority of users can't even contribute anymore, and making this forking feature mandatory makes that situation worse.
Comment #153
dwwThere's nothing forced here on anyone. Projects can (and some probably will) continue to be entirely patch based. If you want to put a note on your project page(s) and/or in the help text for issues in your queue(s) saying "I'm not going to look at merge requests, please only upload patches.", that's 100% your call. You can even add that to the default issue template for your project if you want. ;) Folks might create issue forks for some of your issues, anyway. You don't have to look at them. If folks would rather collaborate via a git repo and you just see the stream of activity in your issues like they were uploading patches, cool. If you never want to create an issue fork or work that way, you don't have to. Until you run into a project maintainer that will *only* accept a MR, in which case, at least they're still on d.o at all and didn't move to GitHub or Gitlab or whatever. That'd definitely be forcing a different workflow on you. This change is meant to help prevent that.
And yes, the docs for this (and nearly every part of Drupal) always need more help. :)
And yes, the notifications don't always go out early enough for everyone's liking... thanks for raising the alarm and helping to instigate the notifications we did get.
Cheers,
-Derek
Comment #154
hestenet@TR - I don't know how to correct the misconception that this was going to be a per-project optional feature after it left beta. This has to be one of the most overcommunicated features in the history of Drupal.org, apart from the maintainer wide emails (you were correct on that front, one at the beginning of beta setting expectations would have been appropriate).
I'm certainly willing to discuss this further with you, and get feedback with any other users who agree - though I think we should perhaps do so in the meta, since this thread was specifically related to the beta process for this feature.
The larger meta is here: #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces