> Faqs > Despliegue Git falla por cambios realizados en composer.lock ¿Qué hacer?

Despliegue Git falla por cambios realizados en composer.lock ¿Qué hacer?

Estoy haciendo un despliegue en el servidor remoto de una actualización de un sitio. El despliegue (deploy) lo hago mediante git. Con el típico "git pull". El caso es que me informa que hay un archivo llamado "composer.lock" que se ha modificado en local (En este contexto local se refiere al servidor remoto) y me sugiere que haga un commit o que haga un stash.

El error que recibo es el siguiente:

Updating 2e7e4c5a..e559d920
error: Your local changes to the following files would be overwritten by merge:
	composer.lock
Please commit your changes or stash them before you merge.
Aborting

Sobre las sugerencias que me ofrece, no sé cuál sería la más adecuada desde el punto de vista del archivo composer.lock.

  • Commit de los cambios: la verdad no lo veo necesario, pues yo realmente no he tocado nada en este archivo y con esta actualización las dependencias de composer cambian, lo que indica que voy a tener que hacer de nuevo el composer install y este archivo se va a tener que modificar de nuevo en ese proceso.
  • Stash: No entiendo muy bien qué es el stash, la verdad. Así que no sé qué tendría que hacer y si realmente eso es lo que quiero.

¿Alguien sugiere alguna otra posibilidad para solucionar esta situación con el composer.lock?

Respuestas

Por la situación que describes creo que has realizado una acción desaconsejada en tu servidor. Si en tu servidor se ha modificado composer.lock es que debes haber ejecutado el "composer update", inadecuadamente. Me explico.

En el servidor remoto, producción, no se debe ejecutar el comando "composer update". Este comando se encarga de actualizar todas las dependencias a los números de versión posibles más nuevos. Como resultado de este comando las dependencias se actualizan y también se actualiza el archivo composer.lock, definiendo las versiones exactas de todas las dependencias que se están instalando. Ese archivo composer.lock nunca debería escribirse en el servidor en producción.

Por tanto, el comando composer update sólo se debe ejecutar en tu ordenador de desarrollo. Al subirse el proyecto, el composer.lock se subirá informando al servidor de las versiones concretas que se han instalado sobre las dependencias.

En cambio, en el servidor en producción siempre se tiene que instalar las dependencias con:

composer install

Este comando "composer install" se apoya en composer.lock para instalar lo que realmente se necesita y tal como está en el ordenador de desarrollo. Además, composer install nunca modifica el composer.lock, por lo que no te debería dar problemas como el que describes cuando actualizas el código del proyecto a las nuevas versiones con "git pull".

Este comportamiento es perfectamente normal, ya que hacer un "composer update" es un proceso muy costoso en términos de CPU y RAM y es muy normal que el servidor falle al ejecutarse, porque suelen estar bastante limitados de recursos. Pero realmente este no sería el único motivo de no hacer el "composer update", sino básicamente también porque no deberían actualizarse las dependencias en remoto, sino primero en local y, comprobando que funciona todo bien, lo normal sería instalarlo en remoto más tarde.

En resumen, el composer.lock nos ayuda a fijar las versiones que tenemos de las dependencias, en todas las instalaciones del proyecto, por lo que no se debería modificar en el servidor en producción, sino solamente en el ordenador de desarrollo.

Ya para solucionar tu problema la idea sería:

  • Hacer el checkout del composer.lock, para descartar todos los cambios realizados.
  • Hacer el pull del repositorio
  • Instalar las dependencias con "composer install"

Los comandos serían los siguientes:

sudo git checkout -- composer.lock
sudo git pull
composer install
Alfonso
289 11 19 16

El composer.lock no solo se ve modificado cuando se actualizan dependencias sino también cuando se instalan nuevas dependencias (ya que cambiara el valor del hash y hará una fotografía de las versiones de las dependenciasinstalas). Yo cuando me he visto con conflictos (al hacer un merge o un pull) en git en los ficheros composer.json o composer.lock lo he solucionado revirtiendo mis cambios, aceptando todos los cambios tal cual vienen de la rama origen y volviendo a recrear mis cambios en composer. Es la única manera en la que he conseguido mergear correctamente los conflictos en cualquiera de esos ficheros.

Edgar
5 1
Gracias Edgar por las sugerencias!!

El comando stash sirve para hacer un guardado provisional de los cambios de un archivo. El caso más habitual es que estés trabajando en una rama y quieras pasarte a otra. Para ello tendrías que confirmar los cambios de tus archivos de la rama actual, porque si no no te deja cambiar de rama. Entonces, para evitar hacer un commit, puedes hacer un "git stash". Efectivamente, no creo que sea este tu caso.

Para el caso del composer.lock yo tampoco veo muy apropiado hacer el commit, además eso luego te puede dar problemas al hacer el "git pull" por necesidad de hacer un merge entre los contenidos de la rama que estás actualizando en el servidor remoto y los contenidos del composer.lock que has conformado. Te tocaría resolver un montón de conflictos sobre el archivo... y es un poco pesado.

Otra sugerencia, que es la que yo prefiero, es descartar los cambios realizados en el composer.lock. Y luego correr el comando install update para instalar las dependencias nuevas de tu proyecto. Serían estos comandos de consola:

sudo git checkout -- composer.lock
sudo git pull
composer install

El composer install instalará las dependencias tal como están definidas en tu archivo composer.json y no modificará ese archivo, con lo que no volverás a tener este problema en tu servidor. Creo que es lo mejor.

Camila
640 27 42 6
Según leo en la otra respuesta, el comando "composer update" se debe ejecutar en local y no en el servidor de producción. Gracias de todos modos. Gracias por el comentario. He corregido mi respuesta.