Combinando GitLab y Composer en nuestros proyectos

En anteriores entradas se ha hablado sobre qué es GitLab y qué es Composer. En esta ocasión vamos a combinar estas dos herramientas para la gestión e instalación de proyectos, librerías, plugins o lo que se nos pueda ocurrir, almacenados en un repositorio de GitLab privado.

Cuando queremos instalar un paquete que está en un repositorio privado o no está dado de alta en Packagist, tenemos que usar la configuración de repositories del archivo «composer.json» y declarar la ruta del paquete.

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/{user}/{repository}"
        }
    ],
    "require": {
        "{user}/{repository}": "^0.0.1"
    }
}

Con esta configuración ya podemos instalar y gestionar un paquete que no esté en Packagist. Lo malo es que tendríamos que hacer esto por cada paquete que usemos en nuestro proyecto, lo cual puede llegar a ser molesto y poco práctico.

¿Qué se puede hacer si tengo GitLab y quiero gestionar los paquetes que están con Composer?

En el momento de definir un repositorio hay diferentes tipos, como vcs, pear, git, package y composer. La opción que vamos a usar y que nos alegrará el día es la de Composer. Ésta busca un «composer.json« en la URL que definimos, el cual nos permite buscar e instalar paquetes como si fuera Packagist desde la consola.

La empresa WeMakeCustom compartió la herramienta «gitlab-composer«en su página de GitHub, que genera un «composer.json» con la información de los proyectos de nuestro GitLab que tengan configurado un «composer.json» que defina como un paquete de Composer.

{
    "packages": {
        "my-group/my-project": {
            "dev-master": {
                "name": "my-group/my-project",
                "source": {
                    "reference": "882816c7c05b5b5704e84bdb0f7ad69230df3c0c",
                    "type": "git",
                    "url": "[email protected]:my-group/my-project.git"
                },
                "type": "project",
                "version": "dev-master"
            },
            "v1.5": {
                "name": "my-group/my-project",
                "source": {
                    "reference": "882816c7c05b5b5704e84bdb0f7ad69230df3c0c",
                    "type": "git",
                    "url": "[email protected]:my-group/my-project.git"
                },
                "type": "project",
                "version": "v1.5"
            }
        }
    }
}

 

¿Cómo se instala «gitlab-composer»?

Para instalar gitlab-composer, en nuestro servidor clonamos el proyecto «https://github.com/wemakecustom/gitlab-composer» e instalamos con Composer las librerías que requiere «composer install».

Dentro del directorio config se encuentra el subdirectorio samples en el cual encontramos el archivo «gitlab.ini« que es una plantilla para la configuración de uso; se copia el archivo al directorio config y al editar este archivo, vemos que solo tiene 3 parámetros de configuración:

• endpoint=»http://gitlab.example.com/api/v3/»
• api_key=»ASDFGHJKL12345678″
• method=»http»

El parámetro endpoint nos pide la URL de la API de nuestro GitLab, que es con la que se comunica para obtener la información y generar el «composer.json».

La api_key tiene que ser la de un usuario que tenga privilegios para ver todos los proyectos o por seguridad un usuario comodín, el cual se añade a los proyectos de este tipo y que solo pueda verlos (limitamos sus privilegios).

Y la última opción method es para seleccionar el método de descarga de los proyectos, el cual puede ser por ssh o http, de los cuales recomiendo el método de http.

¿Cómo lo uso?

Con la información que se genera en el «composer.json» de nuestro servidor, ahora sólo tendríamos que agregar estas líneas:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://gitlab.example.com"
        }
    ]
}

Con esto, al usar el comando «composer search» los primeros resultados serán los de nuestro repositorio. Si por alguna razón, no queremos que se vean o instalen los paquetes que están en Packagist, se puede deshabilitar, quedando tal que así:

{
    "repositories": [
        {
            "packagist": false
        },
        {
            "type": "composer",
            "url": "https://gitlab.example.com"
        }
    ]
}

Con todo esto solo nos queda ejecutar un «composer require» con uno de nuestros paquetes privados y usarlo felizmente.

Un ejemplo de «composer search» contra nuestro GitLab:

 

 

¡Nos veremos en próximos posts de Composer!