aboutsummaryrefslogtreecommitdiffhomepage
path: root/build.xml
diff options
context:
space:
mode:
authorJeremy Benoist <jeremy.benoist@gmail.com>2016-01-20 18:49:45 +0100
committerJeremy Benoist <jeremy.benoist@gmail.com>2016-01-20 18:49:45 +0100
commit173629a4002de5091f41cad4891cca6c8490a7ca (patch)
tree914c7184d511b4e70d9d6b8f9dea2b406ba67f0f /build.xml
parentd481f42b7d383eb6211d1d3049d1a2c8288d9edb (diff)
downloadwallabag-173629a4002de5091f41cad4891cca6c8490a7ca.tar.gz
wallabag-173629a4002de5091f41cad4891cca6c8490a7ca.tar.zst
wallabag-173629a4002de5091f41cad4891cca6c8490a7ca.zip
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.
Diffstat (limited to 'build.xml')
-rw-r--r--build.xml2
1 files changed, 1 insertions, 1 deletions
diff --git a/build.xml b/build.xml
index ab8cac29..3d82770f 100644
--- a/build.xml
+++ b/build.xml
@@ -11,7 +11,7 @@
11 11
12 <target name="composer" description="Install deps using Composer"> 12 <target name="composer" description="Install deps using Composer">
13 <exec executable="composer"> 13 <exec executable="composer">
14 <arg value="install"/> 14 <arg value="up"/>
15 <arg value="--no-interaction"/> 15 <arg value="--no-interaction"/>
16 <arg value="--no-progress"/> 16 <arg value="--no-progress"/>
17 </exec> 17 </exec>