We've been using Travis CI for weeks on this project without issue, now suddenly our builds are failing because of "uncommitted changes". I've no idea why.
- Upgrading ramsey/collection (1.1.1 => 1.1.3): Checking out 28a5c4ab2f from cache
- Upgrading brick/math (0.9.1 => 0.9.2): Checking out dff976c2f3 from cache
- Upgrading symfony/translation (v5.2.1 => v5.2.5): Checking out 0947ab1e3a from cache
[RuntimeException]
Source directory /home/travis/build/vendor/nesbot/carbon has uncommitted changes.
What's strange is that our .travis.yml file hasn't changed at all.
language: php
php:
- 7.3
services:
- mysql
before_install:
- mysql -e 'CREATE DATABASE travis_test;'
cache:
directories:
- node_modules
- vendor
before_script:
- cp .env.travis .env
- sudo mysql -e 'create database homestead;'
- composer self-update
- composer install --prefer-source --no-interaction --dev
- php artisan key:generate
- php artisan migrate --no-interaction -vvv
- php artisan import:required-data
script:
- php artisan test
notifications:
email: false
What is causing this "uncommitted changes" error? How can I fix it?
Travis CI stores a cache of your vendor folder. Sometimes if you've performed a composer update locally it can cause some issues with that cached folder. The solution is to clear your caches and force Travis CI to build everything from scratch again.
To do this, go to your project in Travis CI, click More options > Caches. And on that page you can clear all your caches. Then ask Travis CI to rebuild.
It will take a lot longer the first time, but it should clear this error message.
Related
env: macOS 12.6.3
Docker, Composer, PHP installed
Hello, I’m wondering if you have to manually install sail using
php artisan sail:install
every time I create projects.
Although I have installed laravel projects several times successfully, now it says “no configuration file provided: not found” when sail up when installing a new project and sail up. And there’s no docker-compose.yml file.
The question is that I need to manually install sail every time I make Laravel projects despite the fact that it did automatically installed sail before.
Thank you.
I have tried
php artisan sail:install
We have a CI&CD process that have a dockerfile within for deploying to laravel vapor environments via bitbucket pipeline which consists of 4 basic steps:
Install
Build
Test
Deploy
The interesting point is that, we're passing 3 steps without any problems.
We can run the same command on the 4th step on our local environment and deploy to any environments without any problems.
But when we're trying to deploy it via Bitbucket Pipeline (which was already working 10 days ago but broken now) we're failing with an error message of
In ClassLoader.php line 571:
include(/opt/atlassian/pipelines/agent/build/.vapor/build/app/vendor/compos
er/../composer/composer/src/Composer/Console/GithubActionError.php): Failed
to open stream: No such file or directory
on composer install command.
Our current pipeline configuration:
image: lorisleiva/laravel-docker:8.0
definitions:
steps:
- step: &Install
name: Install
script:
- npm ci
- composer install
- composer dump-autoload
artifacts:
- node_modules/**
- vendor/**
- step: &Build
name: Build
script:
- npm run prod
artifacts:
- public/**
- vendor/**
- step: &Test
name: Test & Lint
script:
- php -d memory_limit=4G vendor/bin/phpstan
- vendor/bin/phplint ./ --exclude=vendor
- vendor/bin/phpunit --coverage-text --colors=never
caches:
node: node_modules
composer: vendor
public: public
pipelines:
branches:
release/test:
- step: *Install
- step: *Build
- step: *Test
- step:
name: Release to Vapor [test]
services:
- docker
script:
- COMMIT_MESSAGE=`git log --format=%B -n 1 $BITBUCKET_COMMIT`
- vendor/bin/vapor deploy test --commit="$BITBUCKET_COMMIT" --message="$COMMIT_MESSAGE"
our test dockerfile for vapor
FROM laravelphp/vapor:php80
COPY . /var/task
and our vapor configuration:
build:
- "COMPOSER_MIRROR_PATH_REPOS=1 composer install --no-dev"
- "php artisan event:cache"
- "npm ci && npm run prod && rm -rf node_modules"
deploy:
- "php artisan migrate"
- "php artisan lighthouse:clear-cache"
Tried to remove composer cache on bitbucket pipeline config.
Read composer cache not working on bitbucket pipeline build and https://github.com/lorisleiva/laravel-docker/issues/67 but still have no idea why it is happening so any help or suggestions are more than welcome.
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:
preparation stage runs the "composer" job, which runs composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
testing stage runs the "phpunit" job
deploy stage runs our Vapor deploy script, which runs COMPOSER_MIRROR_PATH_REPOS=1 composer install --prefer-dist --no-ansi --no-interaction --no-progress --optimize-autoloader --no-dev
So, 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 removals
That 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.
Source here https://github.com/lorisleiva/laravel-docker/issues/67#issuecomment-1009419913
I'm having the same issue.
Is working fine if I remove on vapor.yaml file " --no-dev" in this line.
- 'COMPOSER_MIRROR_PATH_REPOS=1 composer install'
Of course is not a solution, but maybe it helps to identify the issue.
I was having same issue but finally fixed.
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
I am using gitlab pipeline with same lorisleiva/laravel-docker:8.0 image. Further investigation i found composer self-update gives Command "self-update" is not defined. so i thought it is about composer.
So i change .gitlab.ci.yml file like this;
- curl -sS https://getcomposer.org/installer | php
- ./composer.phar -V
- ./composer.phar install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts --ignore-platform-reqs
So i download new composer.phar file and used that instead of default composer command and it is worked.
I got some weird error code after I pulled a project out of my github. My first things I do is composer dumpautoload, composer update, and php artisan migrate:fresh --seed whenver I get to a new terminal. This time, I'm stuck at dumpautoload as it generates this error.
Here's what composer update generated
Loading composer repositories with package information
The "https://repo.packagist.org/packages.json" file could not be downloaded: SSL: An existing connection was forcibly closed by the remote host.
send of 158 bytes failed with errno=10054 An existing connection was forcibly closed by the remote host.
failed to open stream: HTTP request failed!
https://repo.packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date
Updating dependencies (including require-dev)
Nothing to install or update
Writing lock file
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> #php artisan package:discover --ansi
Discovered Package: awobaz/compoships
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: intervention/image
Discovered Package: laravel/tinker
Discovered Package: laravel/ui
Discovered Package: maatwebsite/excel
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Discovered Package: spatie/laravel-medialibrary
Discovered Package: yajra/laravel-datatables-oracle
Package manifest generated successfully.
Script #php artisan package:discover --ansi handling the post-autoload-dump event returned with error
code -1073741819
Old (cached) local dependencies or composer.lock file may causes problem like this. You can try to reinstall all dependencies after remove all dependencies and lock file.
To remove downloaded dependencies, execute this inside app base dir;
sudo rm -rf vendor/
after that delete composer.lock file by executing;
sudo rm composer.lock
and finally execute;
composer install
Just delete the vendor file and install the composer again composer install
To resolve this, configure composer to use the https repository by running the following command on the cli before installing Laravel
composer config -g repo.packagist composer https://packagist.org
Try to create a new laravel project,
and use the new files under the storage/ & bootstrap/cache
to replace the files in the original folders.
I had the same issue and tried re-establishing the dependancies but this did not work for me. It turned out that it was the DB schema causing the issue. More specifically - I had a legacy table named settings. Once I renamed this table and followed up with composer install, the problem was solved.
I think this is due to a spatie package that creates a settings table for itself.
I've seen that XDebug throws Segmentation Fault under PHP 7, that has been happening me and many others. So I got to the solution of running phpdbg with PHP 7 instead of using XDebug.
My question is how should I configure travis.yml to execute one or the other according to the PHP version I'm testing on.
This is my current config file for PHP 7, also available here
language: php
php:
- "5.6"
- "7.0"
install:
- composer self-update
before_script:
- phpenv config-rm xdebug.ini
- mv .env.travis .env
- mv travis.phpunit.xml phpunit.xml
- mysql -e 'create database test_timegrid;'
- composer install --dev --no-interaction
- php artisan config:clear
- php artisan migrate
- php artisan db:seed
- php artisan geoip:update
- php artisan config:cache
script:
- phpdbg -qrr vendor/bin/phpunit --coverage-clover build/logs/clover.xml
after_success:
- ./travis-codeclimate-report.sh
With these setting I can't run tests for PHP 5.6, and when using XDebug those fail for PHP7, so I have kind of a mutual exclusion problem.
Any hints on this?
This is the Travis builds history and the current project files for PHP 5.6
Since there seem to be work-in-progress in this scenario I've decided to continue using XDebug until I can fully move to PHPDebug and use it for PHP7+ and PHP5.6.
At this point, builds with XDebug + PHP7.1 are going well but throws sementation fault for PHP7.0. However, this is sort of ok for me, for now.
Build logs:
https://travis-ci.org/timegridio/timegrid/builds/173947875
I am creating an open source project written in PHP and I'm starting to use Travis CI for testing on PHP versions 5.4, 5.5, 5.6 and HHVM.
The tests for 5.5, 5.6 and HHVM pass without any issues, but I get an error on PHP 5.4.
The error is listed here: https://travis-ci.org/CodeRichard/simple-config/jobs/58154496
I noticed it had something to do with the PHPUnit package which I use for local development and pulled in using Composer. This version requires symfony/yaml ~2.1|~3.0. After a bit of googling, I found out the pipe symbol is used as an OR symbol. This bit confuses me a little.
When I read ~2.1|~3.0 I assume it'll try to pull in one and if it fails, the other. I know symfony/yaml 3.* requires PHP 5.5.9, whereas 2.* requires 5.3.9.
What I don't understand is why it fails. Isn't it supposed to pull in symfony/yaml 2.* instead?
Right now, I'm requiring PHPUnit 4.6.* for development. The requirement for PHPUnit is PHP 5.3.3. However, Composer fails when trying Travis CI is trying to test for PHP 5.4. This makes absolutely no sense. If it would crash on PHP 5.4 and PHPUnit 4.6 requires symfony/yaml 3.0, shouldn't the requirement be 5.5?
I know I can just downgrade PHPUnit to 4.5, but I wish to remain up to date, so I'd rather not.
That error message is simple: Composer cannot install a component that got recorded in the composer.lock file, but doesn't match the requirements of THIS PHP:
symfony/yaml 3.0.x-dev requires php >=5.5.9
This will not work with PHP 5.4.
Downgrading your development machine to 5.4 and run composer update again will fix it.
Running composer update instead of composer install in Travis CI will also fix it. If you decide to do this, you should also run Travis with composer update --prefer-lowest to test that your declared minimum versions are correctly working.
You should also try to avoid "minimum-stability":"dev", unless you are really sure that you need bleeding-edge packages. Currently you are using no other packages, so it's not necessary to deal with the issues of unstable dev versions.
Remove composer.lock
This is what I have in my .travis.yml
# ...
before_script:
- rm composer.lock
- composer install --no-interaction --prefer-source
# ...
Issue: #2823