cweagans / composer-patches

Simple patches plugin for Composer
https://www.cweagans.net/project/composer-patches
BSD 3-Clause "New" or "Revised" License
1.53k stars 240 forks source link

Could not apply patch! Skipping. The error was: Cannot apply patch #226

Closed vouza closed 1 year ago

vouza commented 6 years ago

For some reason I cannot use this plugin. I thought its a user rights thing so I gave 777 to the whole folder. Still it does not work.

The patch is ok. I just was able to include it by using phpstorm.

Thanks for help

$ composer update
    1/1:    http://packagist.org/p/provider-latest$40d29078e846e543e38d2771c7c700e88dfe049917735d752cc3fa12fa9f051d.json
    Finished: success: 1, skipped: 0, failure: 0, total: 1
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/paragraphs (dev-1.x bedd55b): Cloning bedd55bbac from cache
  - Applying patches for drupal/paragraphs
    https://www.drupal.org/files/issues/embed_paragraph_content-2848878-43.patch (Add startup configuration for PHP server)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/embed_paragraph_content-2848878-43.patch
    https://www.drupal.org/files/issues/2868155-16.patch (Issue #2868155: new hooks for editing paragraphs subforms)

> Drupal\Core\Composer\Composer::vendorTestCodeCleanup
Writing lock file
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
PradipShrestha commented 6 years ago

Same issue

ucola commented 6 years ago

Same issue

cweagans commented 6 years ago

If you're getting "Cannot apply patch", it's likely because your patch does not apply. In this case, you're attempting to apply the patch from https://www.drupal.org/project/paragraphs/issues/2868155#comment-12261810, and it doesn't apply because it was already committed to the 8.x-1.x branch in that module repo. You don't even need that patch anymore.

ucola commented 6 years ago

no, the problem is on a custom patch (i.e. for .htaccess)

cweagans commented 6 years ago

@ucola I was referring to the OP. For your case, I can't say for certain, but if the words "Cannot apply patch" appear in the output, it's probably because the patch doesn't apply. See if you can apply it manually with patch, and if not, fix your patch and everything should start working again.

ucola commented 6 years ago

@cweagans thank you for your answer, the patch is very easy, you can see it here: https://drupal-patch.soul.media/drupal8/core/htaccess-003.patch and with patch it works fine...

patch --force .htaccess < htaccess-003.patch Hmm... Looks like a unified diff to me... The text leading up to this was:

|diff --git a/.htaccess b/.htaccess |index 83cb71a..e2df83f 100644 |--- a/.htaccess |+++ b/.htaccess

Patching file .htaccess using Plan A... Hunk #1 succeeded at 15 (offset 14 lines). Hunk #2 succeeded at 89 with fuzz 2 (offset 6 lines). Hunk #3 failed at 128. 1 out of 3 hunks failed--saving rejects to .htaccess.rej done

cweagans commented 6 years ago

1 out of 3 hunks failed--saving rejects to .htaccess.rej

The patch doesn't apply.

ucola commented 6 years ago

@cweagans sorry my fault, i was retrying.... check now the output

as first, i try to do a composer update, the output was this here

Gathering patches for dependencies. This might take a minute.

after this, i try to patch the file manually... and it works

patch --force .htaccess < htaccess-003.patch Hmm... Looks like a unified diff to me... The text leading up to this was:

|diff --git a/.htaccess b/.htaccess |index 83cb71a..e2df83f 100644 |--- a/.htaccess |+++ b/.htaccess

Patching file .htaccess using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 83. Hunk #3 succeeded at 122. done

cweagans commented 6 years ago

Can you supply a complete composer.json that reproduces the problem?

ucola commented 6 years ago

Of corse....

composer.json

{ "name": "drupal/drupal", "description": "Drupal is an open source content management platform powering millions of websites and applications.", "type": "project", "license": "GPL-2.0-or-later", "require": { "composer/installers": "^1.0.24", "wikimedia/composer-merge-plugin": "^1.4", "drupal/core": "^8.5", "cweagans/composer-patches": "^1.6" }, "minimum-stability": "dev", "prefer-stable": true, "config": { "preferred-install": "source", "autoloader-suffix": "Drupal8", "sort-packages": true }, "extra": { "patches-file": "composer.patches.json", "_readme": [ "By default Drupal loads the autoloader from ./vendor/autoload.php.", "To change the autoloader you can edit ./autoload.php.", "This file specifies the packages.drupal.org repository.", "You can read more about this composer repository at:", "https://www.drupal.org/node/2718229" ], "merge-plugin": { "include": [ "core/composer.json" ], "recurse": true, "replace": false, "merge-extra": false }, "installer-paths": { "core": ["type:drupal-core"], "modules/contrib/{$name}": ["type:drupal-module"], "libraries/{$name}": ["type:drupal-library"], "profiles/contrib/{$name}": ["type:drupal-profile"], "themes/contrib/{$name}": ["type:drupal-theme"], "drush/contrib/{$name}": ["type:drupal-drush"], "modules/custom/{$name}": ["type:drupal-custom-module"], "themes/custom/{$name}": ["type:drupal-custom-theme"] } }, "autoload": { "psr-4": { "Drupal\Core\Composer\": "core/lib/Drupal/Core/Composer" } }, "scripts": { "pre-autoload-dump": "Drupal\Core\Composer\Composer::preAutoloadDump", "post-autoload-dump": "Drupal\Core\Composer\Composer::ensureHtaccess", "post-package-install": "Drupal\Core\Composer\Composer::vendorTestCodeCleanup", "post-package-update": "Drupal\Core\Composer\Composer::vendorTestCodeCleanup", "drupal-phpunit-upgrade-check": "Drupal\Core\Composer\Composer::upgradePHPUnit", "drupal-phpunit-upgrade": "@composer update phpunit/phpunit --with-dependencies --no-progress", "phpcs": "phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --", "phpcbf": "phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --" }, "repositories": [ { "type": "composer", "url": "https://packages.drupal.org/8" } ] }

composer.patches.json

{ "patches": { "drupal/core": { "Date between view": "https://www.drupal.org/files/issues/2786577-270_0.patch", "Composer Test error": "https://drupal-patch.soul.media/drupal8/core/composer_error-005.patch", ".htaccess": "https://drupal-patch.soul.media/drupal8/core/htaccess-003.patch" } } }

ucola commented 6 years ago

@cweagans any ideas for our issue?

cweagans commented 6 years ago

The drupal/core package doesn't have .htaccess. You're trying to patch a nonexistent file.

ucola commented 6 years ago

Realy? How we can execute a patch for the .htaccess or a robots.txt?

cweagans commented 6 years ago

Just change the file and commit it. IMO, you should do that with anything outside the core/ directory or any other composer-installed packages.

ucola commented 6 years ago

You mean to create a own repository for this files?

fgm commented 6 years ago

I have had a similar issue with several patches ( https://www.drupal.org/files/issues/2018-03-13/0001-Issue-2912779-by-JulienD-Drush-9-commands.patch and https://www.drupal.org/files/issues/2018-06-05/0001-Issue-2968172-by-WidgetsBurritos-fgm-Support-Drush-9.patch more specifically) appear recently, and on some instances only. They work on some machines and not others, with the same composer.json/composer.lock. When going to the module directories and doing a "git apply" with the downloaded patch files, they apply without error.

Stranger then. When doing "composer install" a second time, the patches apply flawlessly. Shortened example:

First pass

composer install -n --prefer-dist
(snip)
 - Installing drupal/xmlsitemap (dev-1.x 7e435d8): Cloning 7e435d8038 from cache
  - Applying patches for drupal/xmlsitemap
    https://www.drupal.org/files/issues/2018-06-05/0001-Issue-2968172-by-WidgetsBurritos-fgm-Support-Drush-9.patch (2968172-drush-9)
  - Installing drupal/stage_file_proxy (dev-1.x 4c3fa8d): Cloning 4c3fa8d127 from cache
  - Applying patches for drupal/stage_file_proxy
    https://www.drupal.org/files/issues/2018-03-13/0001-Issue-2912779-by-JulienD-Drush-9-commands.patch (2912779-Drush-9)
  - Updating drupal/calendar dev-1.x (73e2979 => 1ef5b86):  Checking out 1ef5b86b11
  - Updating drupal/devel dev-1.x (e41485e => 6848e73):  Checking out 6848e73d8b
  - Updating drupal/paragraphs dev-1.x (ea257e4 => ae73560):  Checking out ae73560831
  - Updating drupal/stage_file_proxy dev-1.x (6d9fd4b => 4c3fa8d):  Checking out 4c3fa8d127
  - Applying patches for drupal/stage_file_proxy
    https://www.drupal.org/files/issues/2018-03-13/0001-Issue-2912779-by-JulienD-Drush-9-commands.patch (2912779-Drush-9)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-03-13/0001-Issue-2912779-by-JulienD-Drush-9-commands.patch
  - Updating drupal/xmlsitemap dev-1.x (23b04ea => 7e435d8):  Checking out 7e435d8038
  - Applying patches for drupal/xmlsitemap
    https://www.drupal.org/files/issues/2018-06-05/0001-Issue-2968172-by-WidgetsBurritos-fgm-Support-Drush-9.patch (2968172-drush-9)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-06-05/0001-Issue-2968172-by-WidgetsBurritos-fgm-Support-Drush-9.patch

Checking and cleaning up

$ cd web/modules/stage_file_proxy
$ git status
HEAD detached at 4c3fa8d
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   composer.json
    deleted:    stage_file_proxy.drush.inc

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    PATCHES.txt
    src/Commands/
    stage_file_proxy.drush.services.yml
    stage_file_proxy.drush8.inc

no changes added to commit (use "git add" and/or "git commit -a")
$ cd .. ; rm -fr stage_file_proxy
$ cd ../xmlsitemap
HEAD detached at 7e435d8
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   xmlsitemap.routing.yml
    modified:   xmlsitemap_engines/tests/modules/xmlsitemap_engines_test/xmlsitemap_engines_test.routing.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    PATCHES.txt
    composer.json
    drush.services.yml
    src/Commands/

no changes added to commit (use "git add" and/or "git commit -a")
$ cd .. ; rm -fr xmlsitemap
$ cd ../../..

Second pass

$ composer install -n --prefer-dist
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 2 installs, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/xmlsitemap (dev-1.x 7e435d8): Cloning 7e435d8038 from cache
  - Applying patches for drupal/xmlsitemap
    https://www.drupal.org/files/issues/2018-06-05/0001-Issue-2968172-by-WidgetsBurritos-fgm-Support-Drush-9.patch (2968172-drush-9)

  - Installing drupal/stage_file_proxy (dev-1.x 4c3fa8d): Cloning 4c3fa8d127 from cache
  - Applying patches for drupal/stage_file_proxy
    https://www.drupal.org/files/issues/2018-03-13/0001-Issue-2912779-by-JulienD-Drush-9-commands.patch (2912779-Drush-9)
(snip)

And this time everything is OK:

$ cd web/modules/contrib/stage_file_proxy/
$ git status
HEAD detached at 4c3fa8d
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   composer.json
    deleted:    stage_file_proxy.drush.inc

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    PATCHES.txt
    src/Commands/
    stage_file_proxy.drush.services.yml
    stage_file_proxy.drush8.inc

no changes added to commit (use "git add" and/or "git commit -a")
$ cd ../xmlsitemap
$ git status
HEAD detached at 7e435d8
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   xmlsitemap.routing.yml
    modified:   xmlsitemap_engines/tests/modules/xmlsitemap_engines_test/xmlsitemap_engines_test.routing.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    PATCHES.txt
    composer.json
    drush.services.yml
    src/Commands/

no changes added to commit (use "git add" and/or "git commit -a")

Noteworthy

On the first composer install, we see this intriguing sequence, looking only at xmlsitemap:

  1. Installing drupal/xmlsitemap (dev-1.x 7e435d8): Cloning 7e435d8038 from cache
  2. Applying patches for drupal/xmlsitemap (patch URL): no patch error
  3. Install/update other modules
  4. Updating drupal/xmlsitemap dev-1.x (23b04ea => 7e435d8): Checking out 7e435d8038
  5. Applying patches for drupal/xmlsitemap (same patch URL) Could not apply patch! Skipping. The error was: Cannot apply patch (same patch URL)

So apparently, the patch is applied twice failing the second time since it is already patched. And although we have a --prefer-dist, it uses git cloning.

A bit later

One thing I noticed is the fact that the problem happens when using dev branches instead of releases and applying patches to them in a later install. I that case, the module is cloned (from cache), and remains installed as a git repo. Then when the install comes from a later version which now adds a patch, the patching apparently applies once using "git apply" (and works), then (probably because it's a prefer-dist) tries to reapply it with "patch" (and fails, being already patched). So I suppose some code gets confused by having a patched dist install on top of a repository which is actually in VCS form.

fgm commented 6 years ago

Digging around the code, I suspect the culprit is in src/Patches::checkPatches() which fails in this scenario:

Apparently, in this scenario, getPatches does not detect that the component should be added to the remove list, which is needed because the format (VCS/dist) has changed between deployments.

ataylorme commented 6 years ago

I am getting the same "Cannot apply patch" error, even though the patch applies with patch.

andrewtaylor:ataylorme-wordpress/ (master*) $ composer update                                                                                                                         09/12/18 at 4:28:44
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing wpackagist-plugin/lh-hsts (1.23): Loading from cache
  - Applying patches for wpackagist-plugin/lh-hsts
    lh-hsts-get-home-url.patch (Use get_home_url in lh-hsts plugin)
   Could not apply patch! Skipping. The error was: Cannot apply patch lh-hsts-get-home-url.patch

  [Exception]
  Cannot apply patch Use get_home_url in lh-hsts plugin (lh-hsts-get-home-url.patch)!

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

andrewtaylor:ataylorme-wordpress/ (master*) $ patch -p1 < lh-hsts-get-home-url.patch                                                                                                        09/12/18 at 4:29:18
patching file web/wp-content/plugins/lh-hsts/lh-hsts.php

It is a simple, one-line patch. Here are the contents

From 78502e76a598b65d67ae6ea6216f1319debc59e9 Mon Sep 17 00:00:00 2001
From: ataylorme <andrew@ataylor.me>
Date: Wed, 12 Sep 2018 16:16:35 -0700
Subject: [PATCH 1/1] Use get_home_url instead of get_site_url in lh-hsts
 plugin

---
 web/wp-content/plugins/lh-hsts/lh-hsts.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/wp-content/plugins/lh-hsts/lh-hsts.php b/web/wp-content/plugins/lh-hsts/lh-hsts.php
index 434da5e..10ae32e 100644
--- a/web/wp-content/plugins/lh-hsts/lh-hsts.php
+++ b/web/wp-content/plugins/lh-hsts/lh-hsts.php
@@ -43,7 +43,7 @@ if (!class_exists('LH_HSTS_Plugin')) {

            $this->uri = $_SERVER['REQUEST_URI'];
            $this->domain = $_SERVER['HTTP_HOST'];
-           $this->current_domain = get_site_url();
+           $this->current_domain = get_home_url();

            add_action( 'send_headers', array($this, "add_header"));
        }
-- 
2.15.2 (Apple Git-101.1)

I use Composer Patches on Drupal projects without issue using patch URLs from Drupal.org. This is my first attempt to use it with a patch file I created myself.

I thought the patch file might have an issue but it applies with patch and git apply without issue.

I would use those directly but they aren't good options for either to ignore patches already applied.

cweagans commented 6 years ago

@ucola You shouldn't need to create a new repo for the files. You should commit files that aren't managed by composer to the project repository. Changes to those files should be applied directly without composer-patches.

@fgm

They work on some machines and not others, with the same composer.json/composer.lock.

Very likely due to differing versions of patch and/or git. Thanks for the detailed information. I'll look through it and see if there's anything that stands out as a reason why things would be going sideways.

@ataylorme The patch needs to be relative to the root of the package that you're trying to patch (lh-hsts). In your patch, basically just remove all instances of web/wp-content/plugins/lh-hsts/ and it should start working again.

ataylorme commented 6 years ago

The patch needs to be relative to the root of the package that you're trying to patch (lh-hsts). In your patch, basically just remove all instances of web/wp-content/plugins/lh-hsts/ and it should start working again.

Removing instances of web/wp-content/plugins/lh-hsts/ in the patch file still gives Could not apply patch! Skipping. The error was: Cannot apply patch lh-hsts-get-home-url.patch and Cannot apply patch Use get_home_url in lh-hsts plugin (lh-hsts-get-home-url.patch)!

My patch file is in the git root along with composer.json. The file I am trying to patch, in the lh-hsts package, is web/wp-content/plugins/lh-hsts/lh-hsts.php.

The patch file, with relative paths compared to the package installation at web/wp-content/plugins/lh-hsts/, is:

From 78502e76a598b65d67ae6ea6216f1319debc59e9 Mon Sep 17 00:00:00 2001
From: ataylorme <andrew@ataylor.me>
Date: Wed, 12 Sep 2018 16:16:35 -0700
Subject: [PATCH 1/1] Use get_home_url instead of get_site_url in lh-hsts plugin

---
 lh-hsts.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lh-hsts.php b/lh-hsts.php
index 434da5e..10ae32e 100644
--- a/lh-hsts.php
+++ b/lh-hsts.php
@@ -43,7 +43,7 @@ if (!class_exists('LH_HSTS_Plugin')) {

            $this->uri = $_SERVER['REQUEST_URI'];
            $this->domain = $_SERVER['HTTP_HOST'];
-           $this->current_domain = get_site_url();
+           $this->current_domain = get_home_url();

            add_action( 'send_headers', array($this, "add_header"));
        }
-- 
2.15.2 (Apple Git-101.1)

The patch file no longer works with patch using paths relative to the package installation rather than the git root, where the patch file is.

ataylorme commented 6 years ago

I take it back - updating the patch to use paths relative to the package worked when I did the replacement with Vim. Not sure why it failed in Visual Studio Code.

Thanks, @cweagans!

aposudevsky commented 6 years ago

For those who are looking for exact reason why the patch cannot be applied, try running composer install -vvv which means debug level of verbosity. It should give you insight on what's happening. In my case the error was only on the server and pretty stupid and self explanatory :

- Applying patches for ... ... patch '-p1' --no-backup-if-mismatch -d '...' < '...' Executing command (CWD): patch '-p1' --no-backup-if-mismatch -d '..' < '...' sh: patch: command not found

rich1990 commented 6 years ago

@aposudevsky Hey man, i got the you same error Applying patches for ... ... patch '-p1' --no-backup-if-mismatch -d so what's the solution you applied to fix this?

rich1990 commented 6 years ago

@aposudevsky we resolved, you right! was self-explanatory! thank you

guix77 commented 6 years ago

Haha @aposudevsky thanks !!! Sometimes it's so stupid it's even difficult to think about it :)

arijitsdrush commented 5 years ago

Some of the time problem maybe OS does not have patch module install. sudo yum install patch can solve this problem sometime.

ElijahLynn commented 5 years ago

For those who are looking for exact reason why the patch cannot be applied, try running composer install -vvv which means debug level of verbosity. It should give you insight on what's happening. In my case the error was only on the server and pretty stupid and self explanatory :

- Applying patches for ... ... patch '-p1' --no-backup-if-mismatch -d '...' < '...' Executing command (CWD): patch '-p1' --no-backup-if-mismatch -d '..' < '...' sh: patch: command not found

This

Some of the time problem maybe OS does not have patch module install. sudo yum install patch can solve this problem sometime.

and this really saved me after a few hours of debugging why composer wasn't installing certain files!

ElijahLynn commented 5 years ago

I am thinking that we need a PR to output a non-verbose-mode error with a failed return code if the patch binary does not exist.

ElijahLynn commented 5 years ago

related/duplicate: https://github.com/cweagans/composer-patches/issues/245

scottw-finao commented 5 years ago

I recently installed this to implement one of the magento patches for v2.2.4. It worked fine for that. More recently, authorize.net released a patch for the end-of-life of the md5 hash checksum and I get this error on that patch. I tried running the patch manually from the command line and had no problems or errors. But when I run it using the plugin it fails:

Gathering patches for root package.
Removing package magento/module-authorizenet so that it can be re-installed and 
re-patched.
  - Removing magento/module-authorizenet (100.2.0)
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing magento/module-authorizenet (100.2.0): Loading from cache
  - Applying patches for magento/module-authorizenet
    patches/composer/Auth.net.md5.composer-2019-02-27-11-51-12-aemod.patch (MD5 
hash sunset deprecation)
   Could not apply patch! Skipping. The error was: Cannot apply patch patches/composer/Auth.net.md5.composer-2019-02-27-11-51-12.patch

I even tried rebuilding the patch manually in case there were changes in the version installed. Still same error. As I say, it works from the command line just fine:

# patch -p0 < patches/composer/Auth.net.md5.composer-2019-02-27-11-51-12.patch 
patching file vendor/magento/module-authorizenet/Model/Directpost.php
patching file vendor/magento/module-authorizenet/Model/Directpost/Request.php
patching file vendor/magento/module-authorizenet/Model/Directpost/Response.php
patching file vendor/magento/module-authorizenet/etc/adminhtml/system.xml
patching file vendor/magento/module-authorizenet/etc/config.xml
#

(keep in mind, both 'patch' and 'git' are installed as it's working with the other github magento 2 patch for v2.2.4 theme change patch)

ElijahLynn commented 5 years ago

Just a thought, I wonder if it is an issue with the . in the filename that composer patches isn't passing along correctly. An easier way to debug this would be to enable xdebug and put a breakpoint somewhere in patches.php:317-341 to see what is actually going on.

https://github.com/cweagans/composer-patches/blob/17fe17634f1f33a260757f076eb7294f842b4264/src/Plugin/Patches.php#L317-L341

scottw-finao commented 5 years ago

I'm not sure what the github standard is compared to a regular patch file, but I started comparing the diff that was working to the one from authorize.net and noticed that the github patch for the other hotfix used an "a/" prefix on the old and a "b/" prefix on the new files. I tried adding "a/" and "b/" in front of the respective lines in my modified authorize patch file and it appears to have worked.

ElijahLynn commented 5 years ago

That makes sense, glad you got it working and thanks for posting your solution here!

scottw-finao commented 5 years ago

np, thanks for tolerating my frustrated testing. I'm glad it was something simple and stupid.

nicholasscottfish commented 5 years ago

For me, the issue was I had the key wrong in the composer.patches.json. Verbose output helped highlight this to me.

andrewanswer commented 5 years ago

I have same problem; using composer install -vvv shows me what if I have spaces in full path to patch, patch doesn't applied.

tdgroot commented 5 years ago

Also if your system/image uses busybox (for example alpine and php), make sure you install patch separately. For alpine linux, just run: apk add patch.

Prekshapatel commented 4 years ago

I have a Could not apply patch! Skipping. issue while trying to update the drupal core. That patch is mentioned in GOVCMS installation profile composer.json. Issue is patch is already applied for panelizer module and auto generated in (modules/contrib/panelizer/PATCHES.txt) . And there is a project composer file which is outside docroot using which I am trying to update drupal core. There is another patch mentioned in project's composer.json file for the panelizer module. So whenever I try to update the drupal core, panelizer module is getting deleted and trying to apply both the patches one mentioned in GOVCMS composer.json and one mentioned in project's composer.json file. I tried to remove the patch mentioned in GOVCMS composer.json file but still the issue is ther. Can any one tell me how could I remove the patch completely from GOVCMS composer.json, auto generated by cweagans/composer-patches in modules/contrib/panelizer/PATCHES.txt etc?

make-me-a-websiteDOTnet commented 4 years ago

I have a Could not apply patch! Skipping. issue while trying to update the drupal core. That patch is mentioned in GOVCMS installation profile composer.json. Issue is patch is already applied for panelizer module and auto generated in (modules/contrib/panelizer/PATCHES.txt) . And there is a project composer file which is outside docroot using which I am trying to update drupal core. There is another patch mentioned in project's composer.json file for the panelizer module. So whenever I try to update the drupal core, panelizer module is getting deleted and trying to apply both the patches one mentioned in GOVCMS composer.json and one mentioned in project's composer.json file. I tried to remove the patch mentioned in GOVCMS composer.json file but still the issue is ther. Can any one tell me how could I remove the patch completely from GOVCMS composer.json, auto generated by cweagans/composer-patches in modules/contrib/panelizer/PATCHES.txt etc?

I also have the same issue patching drupal/core (while phpstorm apply fine):

composer.json: { "name": "drupal/recommended-project", "description": "Project template for Drupal 8 projects with a relocated document root", "type": "project", "license": "GPL-2.0-or-later", "homepage": "https://www.drupal.org/project/drupal", "support": { "docs": "https://www.drupal.org/docs/user_guide/en/index.html", "chat": "https://www.drupal.org/node/314178" }, "repositories": { "0": { "type": "composer", "url": "https://packages.drupal.org/8" }, "mmaw": { "type": "gitlab", "url": "https://gitlab.com/make-me-a-website.net/mmaw-helper-drupal-8.git" }, "asset-packagist": { "type": "composer", "url": "https://asset-packagist.org" } }, "require": { "composer/installers": "^1.2", "cweagans/composer-patches": "^1.6", "drupal/admin_toolbar": "^2.2", "drupal/adminimal_admin_toolbar": "^1.11", "drupal/adminimal_theme": "^1.5", "drupal/auto_entitylabel": "^3.0@beta", "drupal/blazy": "^2.0", "drupal/block_class": "^1.2", "drupal/block_content_permissions": "^1.9", "drupal/coffee": "^1.0", "drupal/components": "^1.1", "drupal/console": "^1.9", "drupal/core-composer-scaffold": "^8.8", "drupal/core-project-message": "^8.8", "drupal/core-recommended": "^8.8", "drupal/crop": "^2.1", "drupal/ctools": "^3.4", "drupal/devel": "^2.1", "drupal/editor_advanced_link": "^1.8", "drupal/editor_file": "^1.5", "drupal/entity": "^1.0", "drupal/extlink": "^1.3", "drupal/field_permissions": "1.@RC", "drupal/image_widget_crop": "^2.3", "drupal/inline_entity_form": "^1.0@RC", "drupal/link_css": "1.x-dev", "drupal/linked_field": "^1.3", "drupal/linkit": "^4.3", "drupal/menu_link_attributes": "^1.0", "drupal/metatag": "^1.13", "drupal/mmaw_helper": "dev-master", "drupal/pathauto": "^1.8", "drupal/rabbit_hole": "1.@beta", "drupal/redirect": "^1.6", "drupal/sitemap": "^1.5", "drupal/slick": "^2.2", "drupal/svg_image_field": "^1.2", "drupal/theme_breakpoints_js": "^1.0@beta", "drupal/token": "^1.7", "drupal/twig_field_value": "^2.0", "drupal/twig_tweak": "^2.5", "drupal/views_bulk_operations": "^3.6", "drush/drush": "^10.2", "npm-asset/blazy": "^1.8", "npm-asset/slick-carousel": "^1.8", "oomphinc/composer-installers-extender": "^1.1", "symfony/filesystem": "~3.0", "symfony/finder": "~3.0" }, "conflict": { "drupal/drupal": "" }, "minimum-stability": "dev", "prefer-stable": true, "config": { "sort-packages": true }, "extra": { "enable-patching": true, "patches": { "drupal/core": { "dev-services": "patchs/dev-services.patch" } }, "drupal-scaffold": { "locations": { "web-root": "web/" } }, "installer-paths": { "web/core": [ "type:drupal-core" ], "web/libraries/{$name}": [ "type:bower-asset", "type:npm-asset", "vendor:npm-asset", "vendor:bower-asset", "type:drupal-library" ], "web/modules/contrib/{$name}": [ "type:drupal-module" ], "web/profiles/contrib/{$name}": [ "type:drupal-profile" ], "web/themes/contrib/{$name}": [ "type:drupal-theme" ], "drush/Commands/contrib/{$name}": [ "type:drupal-drush" ], "web/modules/custom/{$name}": [ "type:drupal-custom-module" ], "web/themes/custom/{$name}": [ "type:drupal-custom-theme" ] }, "drupal-core-project-message": { "include-keys": [ "homepage", "support" ], "post-create-project-cmd-message": [ " </>", " Congratulations, you’ve installed the Drupal codebase </>", " from the drupal/recommended-project template! </>", " </>", "", "Next steps</>:", " Install the site: https://www.drupal.org/docs/8/install", " Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html", " Get support: https://www.drupal.org/support", " Get involved with the Drupal community:", " https://www.drupal.org/getting-involved", " Remove the plugin that prints this message:", " composer remove drupal/core-project-message" ] }, "installer-types": [ "bower-asset", "npm-asset", "make-me-a-website.net" ] }, "require-dev": { "drupal/stage_file_proxy": "^1.0" } } patch file: Index: web/sites/development.services.yml IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

--- web/sites/development.services.yml (date 1593281726997) +++ web/sites/development.services.yml (date 1593281726997) @@ -4,6 +4,9 @@

'example.settings.local.php' file, which sits next to this file.

parameters: http.response.debug_cacheability_headers: true

Prekshapatel commented 4 years ago

I have a Could not apply patch! Skipping. issue while trying to update the drupal core. That patch is mentioned in GOVCMS installation profile composer.json. Issue is patch is already applied for panelizer module and auto generated in (modules/contrib/panelizer/PATCHES.txt) . And there is a project composer file which is outside docroot using which I am trying to update drupal core. There is another patch mentioned in project's composer.json file for the panelizer module. So whenever I try to update the drupal core, panelizer module is getting deleted and trying to apply both the patches one mentioned in GOVCMS composer.json and one mentioned in project's composer.json file. I tried to remove the patch mentioned in GOVCMS composer.json file but still the issue is ther. Can any one tell me how could I remove the patch completely from GOVCMS composer.json, auto generated by cweagans/composer-patches in modules/contrib/panelizer/PATCHES.txt etc?

I also have the same issue patching drupal/core (while phpstorm apply fine):

composer.json:

{ "name": "drupal/recommended-project", "description": "Project template for Drupal 8 projects with a relocated document root", "type": "project", "license": "GPL-2.0-or-later", "homepage": "https://www.drupal.org/project/drupal", "support": { "docs": "https://www.drupal.org/docs/user_guide/en/index.html", "chat": "https://www.drupal.org/node/314178" }, "repositories": { "0": { "type": "composer", "url": "https://packages.drupal.org/8" }, "mmaw": { "type": "gitlab", "url": "https://gitlab.com/make-me-a-website.net/mmaw-helper-drupal-8.git" }, "asset-packagist": { "type": "composer", "url": "https://asset-packagist.org" } }, "require": { "composer/installers": "^1.2", "cweagans/composer-patches": "^1.6", "drupal/admin_toolbar": "^2.2", "drupal/adminimal_admin_toolbar": "^1.11", "drupal/adminimal_theme": "^1.5", "drupal/auto_entitylabel": "^3.0@beta", "drupal/blazy": "^2.0", "drupal/block_class": "^1.2", "drupal/block_content_permissions": "^1.9", "drupal/coffee": "^1.0", "drupal/components": "^1.1", "drupal/console": "^1.9", "drupal/core-composer-scaffold": "^8.8", "drupal/core-project-message": "^8.8", "drupal/core-recommended": "^8.8", "drupal/crop": "^2.1", "drupal/ctools": "^3.4", "drupal/devel": "^2.1", "drupal/editor_advanced_link": "^1.8", "drupal/editor_file": "^1.5", "drupal/entity": "^1.0", "drupal/extlink": "^1.3", "drupal/fieldpermissions": "1.@rc", "drupal/image_widget_crop": "^2.3", "drupal/inline_entity_form": "^1.0@RC", "drupal/link_css": "1.x-dev", "drupal/linked_field": "^1.3", "drupal/linkit": "^4.3", "drupal/menu_link_attributes": "^1.0", "drupal/metatag": "^1.13", "drupal/mmaw_helper": "dev-master", "drupal/pathauto": "^1.8", "drupal/rabbithole": "1.@beta", "drupal/redirect": "^1.6", "drupal/sitemap": "^1.5", "drupal/slick": "^2.2", "drupal/svg_image_field": "^1.2", "drupal/theme_breakpoints_js": "^1.0@beta", "drupal/token": "^1.7", "drupal/twig_field_value": "^2.0", "drupal/twig_tweak": "^2.5", "drupal/views_bulk_operations": "^3.6", "drush/drush": "^10.2", "npm-asset/blazy": "^1.8", "npm-asset/slick-carousel": "^1.8", "oomphinc/composer-installers-extender": "^1.1", "symfony/filesystem": "~3.0", "symfony/finder": "~3.0" }, "conflict": { "drupal/drupal": "" }, "minimum-stability": "dev", "prefer-stable": true, "config": { "sort-packages": true }, "extra": { "enable-patching": true, "patches": { "drupal/core": { "dev-services": "patchs/dev-services.patch" } }, "drupal-scaffold": { "locations": { "web-root": "web/" } }, "installer-paths": { "web/core": [ "type:drupal-core" ], "web/libraries/{$name}": [ "type:bower-asset", "type:npm-asset", "vendor:npm-asset", "vendor:bower-asset", "type:drupal-library" ], "web/modules/contrib/{$name}": [ "type:drupal-module" ], "web/profiles/contrib/{$name}": [ "type:drupal-profile" ], "web/themes/contrib/{$name}": [ "type:drupal-theme" ], "drush/Commands/contrib/{$name}": [ "type:drupal-drush" ], "web/modules/custom/{$name}": [ "type:drupal-custom-module" ], "web/themes/custom/{$name}": [ "type:drupal-custom-theme" ] }, "drupal-core-project-message": { "include-keys": [ "homepage", "support" ], "post-create-project-cmd-message": [ " </>", " Congratulations, you’ve installed the Drupal codebase </>", " from the drupal/recommended-project template! </>", " </>", "", "Next steps</>:", " Install the site: https://www.drupal.org/docs/8/install", " Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html", " Get support: https://www.drupal.org/support", " Get involved with the Drupal community:", " https://www.drupal.org/getting-involved", " Remove the plugin that prints this message:", " composer remove drupal/core-project-message" ] }, "installer-types": [ "bower-asset", "npm-asset", "make-me-a-website.net" ] }, "require-dev": { "drupal/stage_file_proxy": "^1.0" } } patch file: Index: web/sites/development.services.yml IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 --- web/sites/development.services.yml (date 1593281726997) +++ web/sites/development.services.yml (date 1593281726997) @@ -4,6 +4,9 @@

'example.settings.local.php' file, which sits next to this file.

parameters: http.response.debug_cacheability_headers: true

  • twig.config:
  • debug: true
  • auto_reload: true services: cache.backend.null: class: Drupal\Core\Cache\NullBackendFactory

I have removed patched from the project's composer file then govcms patch applied successfully while running updates and then didn't have to apply the patch mentioned in the project's composer file as it was covered with the govcms patch and module update.

kierandelaney commented 4 years ago

The drupal/core package doesn't have .htaccess. You're trying to patch a nonexistent file.

Just a heads up for anyone who stumbles across this issue/comment now, sometime later, like me. As of Drupal 8.8.x this is no longer true, drupal/core includes the htaccess file in core/assets/scaffold/files/htaccess. Many composer projects then copy this into the relevant directory. If this applies to your set up, simply patch the file inside the scaffold directory to resolve any issues, as the patched file will be copied.

janhavi529 commented 4 years ago

I am using Drupal 9 and getting this error when trying to apply the following patch : Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2020-03-06/3109534-94.patch When using composer install -vvv get the following error: patch '-p4' --no-backup-if-mismatch -d 'web/core' < '/tmp/5f975747689bc.patch' Executing command (CWD): patch '-p4' --no-backup-if-mismatch -d 'web/core' < '/tmp/5f975747689bc.patch' can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? Along with this it fails at multiple lines with the same error. "sudo yum install patch" didn't seem to resolve the error. I am quite new to Drupal and now sure how to resolve this.

Below is a snippet from my composer.json file: "extra": { "drupal-scaffold": { "locations": { "web-root": "web/" } }, "installer-paths": { "web/core": [ "type:drupal-core" ], "web/libraries/{$name}": [ "type:drupal-library" ], "web/modules/contrib/{$name}": [ "type:drupal-module" ], "web/profiles/contrib/{$name}": [ "type:drupal-profile" ], "web/themes/contrib/{$name}": [ "type:drupal-theme" ], "drush/Commands/contrib/{$name}": [ "type:drupal-drush" ], "web/modules/custom/{$name}": [ "type:drupal-custom-module" ], "web/themes/custom/{$name}": [ "type:drupal-custom-theme" ] }, "drupal-core-project-message": { "include-keys": [ "homepage", "support" ], "post-create-project-cmd-message": [ " </>", " Congratulations, you’ve installed the Drupal codebase </>", " from the drupal/recommended-project template! </>", " </>", "", "Next steps</>:", " Install the site: https://www.drupal.org/docs/8/install", " Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html", " Get support: https://www.drupal.org/support", " Get involved with the Drupal community:", " https://www.drupal.org/getting-involved", " * Remove the plugin that prints this message:", " composer remove drupal/core-project-message" ] }, "enable-patching": true, "patches": { "drupal/core": { "The database server version 10.2.10-MariaDB is less than the minimum required version 10.3.7.": "https://www.drupal.org/files/issues/2020-03-06/3109534-94.patch" } } }

FlxAlbroscheit commented 3 years ago

Same error here, however I noticed something interesting:

* Patch 1 (targeting a package under /vendor) applies * Patch 2 (targeting a module under /web/modules/contrib) does NOT apply, throwing above's error. However, applying it manually via "git apply my-patch.patch" works without troubles.

As debugging did not bring in anything of interest, I was wondering whether the file targeted in patch 2 did exist when composer-patches tried to apply it?! Could there be anything like a delay for packages to become copied to their target destination when the latter one is outside of /vendor, thus being "invisible" to composer-patches at that moment?

UPDATE: Make 100% sure that the file path provided at the top of your .patch-file is a path relative to the module/dependency that you would like to patch. This explains why composer-patch fails to apply a patch, but doing the same via "git apply" does work. Instead of e.g. "--- a/src/vendor/name-of-module/name-of-file" the path is sufficient to be "--- a/name-of-file".

cafuego commented 3 years ago

I've run into this when trying to get patches applied in GitHub Actions, during a composer run. Although the patch command says the patches apply OK, composer thinks it returns a non-zero exit status and the composer run fails.

I suspect running under docker messes with the console or stdin, or whatever is providing the shell in the docker container does not like doing redirects (could be busybox?).

After some poking at it, it looks like using the -i parameter for the input patch file, instead of reading from stdin via < resolves my issue. As far as I can tell, that parameter works on all platforms, so it should be a safe change.

The pull request is at https://github.com/cweagans/composer-patches/pull/375

If you want to test this locally, add the git repo as a new repository in composer.json:

    {
       "type": "package",
        "package": {
          "name": "cweagans/composer-patches",
          "version": "dev-master",
          "source": {
            "url": "https://github.com/UN-OCHA/composer-patches.git",
            "type": "git",
            "reference": "master"
          }
        }
      }

and then require cweagans/composer-patches:dev-master

denniskopitz commented 3 years ago

I've reviewed all of the comments here, but can not solve my seemingly simple issue. Hoping some one can point me in the right direction. I need this patch to be applied with composer install to be compatable with our deployment build process.

The file i'm trying to patch has CRLF line endings. My patch file does not. In the verbose output below, you can see the first attempt with -p1 option, failes due to different line endings. (also note in this first attempt, it finds the target file without issue, outputing patching file Model/ResourceModel/Result.php)

The subsequent attempts ( -p0, -p2, -p4) all fail saying they can't find the file.

I have tried many different patch file formats, including relative and absolute paths. I've also tried changing line endings on my patch file to match the target file. For whatever reason, it always seems to fail in the end with can't find file to patch at input line 9

Any guidence would be greatly appreciated.

Here is important output from composer install -vvv:

Found 1 patches for mageme/module-webforms.
  - Installing mageme/module-webforms (2.9.32): Reading /home/magento/.composer/cache/files/mageme/module-webforms/f005131fbfe17c80b3fe7e9c0dd5419fb3330a83.zip from cache
Loading from cache
 Extracting archiveExecuting command (CWD): unzip -qq  '/var/www/html/vendor/mageme/module-webforms/e3619e5c653f2f4d72af36450fd88b1b.zip' -d '/var/www/html/vendor/composer/5c5203b0'
    REASON: Required by the root package: Install command rule (install mageme/module-webforms 2.9.32)

  - Applying patches for mageme/module-webforms
    patches/web_form_date_parse.patch (Fix for error when unholding orders)
Executing command (CWD): patch '-p1' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patch '-p1' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patching file Model/ResourceModel/Result.php

Hunk #1 FAILED at 168 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file Model/ResourceModel/Result.php.rej

Executing command (CWD): patch '-p0' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patch '-p0' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
can't find file to patch at input line 9
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: vendor/mageme/module-webforms/Model/ResourceModel/Result.php
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|diff --git a/vendor/mageme/module-webforms/Model/ResourceModel/Result.php b/vendor/mageme/module-webforms/Model/ResourceModel/Result.php
|--- a/Model/ResourceModel/Result.php
|+++ b/Model/ResourceModel/Result.php   (date 1628090929459)
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

Executing command (CWD): patch '-p2' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patch '-p2' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
can't find file to patch at input line 9
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: vendor/mageme/module-webforms/Model/ResourceModel/Result.php
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|diff --git a/vendor/mageme/module-webforms/Model/ResourceModel/Result.php b/vendor/mageme/module-webforms/Model/ResourceModel/Result.php
|--- a/Model/ResourceModel/Result.php
|+++ b/Model/ResourceModel/Result.php   (date 1628090929459)
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

Executing command (CWD): patch '-p4' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patch '-p4' --no-backup-if-mismatch -d '/var/www/html/vendor/mageme/module-webforms' < '/var/www/html/patches/web_form_date_parse.patch'
patching file Model/ResourceModel/Result.php

Hunk #1 FAILED at 168 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file Model/ResourceModel/Result.php.rej

   Could not apply patch! Skipping. The error was: Cannot apply patch patches/web_form_date_parse.patch

Here is the patch file:

Index: vendor/mageme/module-webforms/Model/ResourceModel/Result.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/vendor/mageme/module-webforms/Model/ResourceModel/Result.php b/vendor/mageme/module-webforms/Model/ResourceModel/Result.php
--- a/Model/ResourceModel/Result.php
+++ b/Model/ResourceModel/Result.php    (date 1628090929459)
@@ -168,9 +168,12 @@
                                 $dateFormat = $field->getDateFormat();
                                 if ($field->getType() == 'datetime')
                                     $dateFormat .= " " . $field->getTimeFormat();
-                                $dateArray = \Zend_Locale_Format::getDateTime($value, [
-                                    'date_format' => $dateFormat
-                                ]);
+                                try {
+                                    $dateArray = \Zend_Locale_Format::getDateTime($value, [
+                                        'date_format' => $dateFormat
+                                    ]);
+                                } catch (\Exception $e) {
+                                }
                                 $date      = new \Zend_Date();
                                 if (!empty($dateArray["year"])) $date->setYear($dateArray["year"]);
                                 if (!empty($dateArray["month"])) $date->setMonth($dateArray["month"]);
samozin commented 2 years ago

it was solved when changed using the cmd.exe with the great git command line cmd.exe is the problem try to use another command line program

sealionking commented 1 year ago

Some of the time problem maybe OS does not have patch module install. sudo yum install patch can solve this problem sometime.

centos 8 stream, it works

cweagans commented 1 year ago

There are a lot of different issues here and many of them are now solved in main. Unfortunately, this plugin will never be able to fix a patch that doesn't apply. You have to give it a valid patch if you want it to work.

DanielRuf commented 1 year ago

I think the composer install -vvv is missing at https://docs.cweagans.net/composer-patches/troubleshooting/guide/. That could have made it much easier in most comments / issues to identify the exact problem instead of the very generic error message.

Besides that, the documentation is unclear about the support for local patches in folders + what the/project has to be. See https://docs.cweagans.net/composer-patches/usage/defining-patches/

rintisch commented 1 year ago

I had the problem in a GitHub Action. While the patch could without any problem be applied on the local system it was not working on in the GitHub Action. When installing with composer install -vvv the error message was sh: patch: not found. With the help of https://github.com/php-actions/composer/issues/98#issuecomment-1551934062 I realized that the problem was my own Docker Image: The apt package patch was missing.