11

The new fork based merge request (MR) approach is pretty neat to get the patches created/reviewed/merged. However, if you are using the patch via cweagans/composer-patches, we have a few options.

Option 1: we can use the MR to add the patch like this:

"drupal/message": {
  "3186091": "https://git.drupalcode.org/project/message/-/merge_requests/1.patch"
}

but it means any new change pushed to the fork/branch, would get automatically added. As the patch file gets pulled on composer install.

Option 2: We could use the fork's branch and commit hash to keep the patch static, but once the MR merged, the fork might get deleted and breaks the build.

Option 3: Obviously we can generate the patch from the MR and upload to the issue comment, but it seems a duplicate effort and hard to keep up with an active core issue (right now, we just need to update the patch file in composer.json or composer.patches.json)

Is there a way to have the current patch file behavior in the new fork based issue queue?

UPDATE: Both option 1 and (probably) option 3 are documented on drupal.org

Improve this question
4
  • Does this answer your question? Require v8 only contrib module with v9 patch
    – leymannx
    Commented Dec 3, 2020 at 14:43
  • 1
    This is slightly related, but not the same. The other questions handles modules without Drupal 9 support (=> composer version conflict), this questions is how to include an immutable patch from the new d.o. issue queue (which does no longer provide immutable patch files).
    – Hudri
    Commented Dec 3, 2020 at 14:50
  • 1
    On one hand I think: This actually is no Drupal-related problem, it's a Gitlab/GitHub-related chicken-egg-problem in general. On the other hand I think you are actually asking: How do I get the old drupal.org behaviour back with GitLab? Option 2 probably sounds like the best: Take the fork's commit patch and later break the build so you know the MR got probably merged and you can update.
    – leymannx
    Commented Dec 3, 2020 at 15:17
  • @leymannx Even if it got merged, that doesn't mean there's a new release available.
    – mbomb007
    Commented Sep 8, 2022 at 15:34

2 Answers 2

Reset to default
4

It has been discussed already in the Opt-in to the Drupal.org Issue Forks and Merge Requests beta thread, see 3152637#comment-13820062. As of now there is no straight way to integrate commits in composer patch work flow. You need to download the patch file manually by appending .patch to the merge request URL and copy it locally into your project to get it applied in the build process.

"patches": {
    "drupal/foobar": {
        "3200808 - Lorem ipsum": "./patches/3200808-3.patch"
    }
}

You can get additional information on how to generate patch from the commit Id from the guide: Patch files for use with Composer.

Improve this answer
1
  • One should use the .diff suffix instead of .patch because the latter will give you a commit-by-commit version which doesn't always apply.
    – Darvanen
    Commented Oct 17, 2023 at 10:43
0

See Drupal documentation to force module installion due to composer restriction. There two options:

  • Using Issue Forks directly
  • OR Use the composer-drupal-lenient Package

@see https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/core-version-compatibility-fixes-for-modules-with-unmerged-changes

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.