mirror of
https://github.com/wallabag/wallabag.git
synced 2024-06-12 18:29:34 +00:00
Ignore composer.lock
Having a big composer.lock on a final project can have side effect on incoming PR that add a new vendor. Mostly because conflict are too frequent. By ignoring composer.lock we ease the PR submission and rebase. BUT we need to be careful when we release a new version of wallabag. We should manually `git add -f composer.lock` to update it. Since composer.lock will no longer be commited I switch the `composer install` to a `composer up` in the travis configuration.
This commit is contained in:
parent
d481f42b7d
commit
173629a400
3
.gitignore
vendored
3
.gitignore
vendored
|
@ -35,3 +35,6 @@ data/db/wallabag*.sqlite
|
||||||
# Docker container logs and data
|
# Docker container logs and data
|
||||||
docker/logs/
|
docker/logs/
|
||||||
docker/data/
|
docker/data/
|
||||||
|
|
||||||
|
# To avoid crazy stuff on some PR, we must manually FORCE ADD IT on each new release
|
||||||
|
composer.lock
|
||||||
|
|
|
@ -11,7 +11,7 @@
|
||||||
|
|
||||||
<target name="composer" description="Install deps using Composer">
|
<target name="composer" description="Install deps using Composer">
|
||||||
<exec executable="composer">
|
<exec executable="composer">
|
||||||
<arg value="install"/>
|
<arg value="up"/>
|
||||||
<arg value="--no-interaction"/>
|
<arg value="--no-interaction"/>
|
||||||
<arg value="--no-progress"/>
|
<arg value="--no-progress"/>
|
||||||
</exec>
|
</exec>
|
||||||
|
|
Loading…
Reference in a new issue