admin1for2
commented
3 years ago I have the exact same problem as you : composer updates failing with error finding the file GithubActionError.php. Did you manage to find a solution ?
Thanks
Closed yoelpc4 closed 3 years ago
admin1for2
commented
3 years ago I have the exact same problem as you : composer updates failing with error finding the file GithubActionError.php. Did you manage to find a solution ?
Thanks
yoelpc4
commented
3 years ago @admin1for2 Nope, current solution is upgrading to 7.3 or 7.4
lorisleiva
commented
3 years ago Sorry guys, this repo no longer maintains versions below 7.3.
Majicbob
commented
3 years ago I ran into this same issue with a forked version of 7.4 After some debugging I wasn't able to determine the root cause but it appeared to be on GitLab's end. Clearing the runner caches on GitLab fixed it for me.
jnbn
commented
2 years ago We're having the same error with 8.0 image and still couldn't find any solutions
fgilio
commented
2 years ago I'm having this exact same issue when using the PHP 8 image, will share any info I find
EDIT: Oooook. We found an acceptable workaround.
TLDR: Run rm -rf ./vendor before your composer install before deploying.
Now to our analysis 👇🏼
We run all our tests and deploys in GitLab CI (thanks to @lorisleiva 🤗 ). And we have 3 jobs in 3 stages:
composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scriptsCOMPOSER_MIRROR_PATH_REPOS=1 composer install --prefer-dist --no-ansi --no-interaction --no-progress --optimize-autoloader --no-devSo, in the composer job we install our dev dependencies because we need them to test the app. The resulting ./vendor directory gets cached by GitLab's CI system and it's automatically made available for the subsequent stages.
That's great, cause it means we install dependencies once and then we can re use that in the testing and deploying stages. So we "deploy the same thing that we tested"...
But that's actually false, cause for production we don't want to install the development dependencies. That's why we use the --no-dev flag in composer in the deploy stage. Keep in mind, we do need those development dependencies to run phpunit.
And when we run it we see a message like:
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 0 installs, 0 updates, 73 removalsThat makes sense, we already have access to the cached ./vendor directory from the composer job and now we only need to remove the development dependencies.
That's when things fall apart. I've no idea if this is a bug in composer itself, in a dependency, in our codebase, etc... but composer errors out with the ...GithubActionError.php error when trying to remove the development dependencies. If we remove the --no-dev it works perfectly, but That's A NoNo.
Long story short, our solution is to embrace the fact that composer.lock exists and that this job runs in CI (where the download speed is insanely fast). So we nuke the ./vendor directory running rm -rf ./vendor right before the deployable composer install ... --no-dev.
In the end, I think this is perfectly acceptable.
I'm sure there's a way to tell GitLab to avoid downloading the cached ./vendor directory, or an overall better way to do this. But we've spent way to much time today trying to understand and fix this... so, it's going to stay like this. And, no, it doesn't seen to be related to lorisleiva/laravel-docker:x.x docker images.
I hope this is helpful or at least interesting :) Please do let me know if anyone finds a better approach.
lorisleiva
commented
2 years ago Hi Franco 👋
Thanks for the detailed report and for sharing it with us!
Do let me know if there's anything this repository can do to improve the developer experience regarding this issue.
hakanersu
commented
2 years ago I had same issue and i found a different solution that i post here https://stackoverflow.com/a/71529389/7736155
include(/builds/myapp/myapp-api/vendor/composer/../composer/composer/sr
c/Composer/Console/GithubActionError.php): Failed to open stream: No such f
ile or directory TL;TD
composer command actually not working as expected i download new composer.phar file and everything works fine now.
Hi @lorisleiva, thanks for writing this helpful article https://lorisleiva.com/using-gitlabs-pipeline-with-laravel/. Here is my following setup:
Between January-November 2020, I faced no critical issue while implementing this package to execute CI/CD along with my laravel 7.2 project on the gitlab shared runner.
Currently I'm encountering a critical issue on my pipeline while the runner executing command
composer install -o --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts.This is the build log from gitlab shared runner
As you can see this is the error thrown from composer
Do you have any idea how to solves this issue?