Catégories
CMS

Gérer son propre serveur Packagist avec Drupal

J’ai récemment écrit un article qui présente l’API de packagist en prenant l’exemple du serveur de Drupal.org.

Il est temps de présenter un module Packagist qui permet de transformer n’importe quel instance Drupal en serveur de paquets PHP compatible avec composer.

Il s’appuie sur l’interface de PackagistUI pour générer les fichiers aux formats qui vont bien, en générant des hash conformes aux standards attendus, et exposer les métadonnées de manière cohérente.

D’autres alternatives sont possibles : je me suis contenté de travailler avec Git, car c’est mon seul besoin 😉

Définir le(s) serveur(s) Packagist

Paramétrer

Il s’agit du serveur qui fournit les métadonnées à composer : autrement dit, l’instance Drupal dont nous sommes en train de parler.

Le détail des champs est présenté ici sur la page de documentation sur D.O.

Il faut faire attention aux points suivants :

  • le champ Base url est un tronçon d’URL, pas une URL absolue
  • le champ Archives base url est une URL absolue

Le genre de détail qui rend un peu fou lorsque l’on n’a pas fait bien attention tout de suite. D’autant qu’il n’y a pas de retour explicite sur le non-fonctionnement que cela cause.

Par ailleurs, la documentation est copiée-collée depuis PackagistUI, donc il n’est pas bien documenté que le dossier doit être impérativement accessible dans le chemin web du serveur.

  • autrement dit, les métadonnées sont nécessairement exposées
  • il n’est pas possible de bloquer l’accès à ces données si c’est le serveur Drupal qui les sert

Sécuriser l’accès

Permission Drupal ?

Pour clarifier ce que fait le code : il ne s’agit pas d’un service web en REST qui retourne les valeurs. Il n’est donc pas possible de sécuriser au travers d’une permission.

Fichiers privés

On peut imaginer paramétrer le chemin vers un dossier privé. Cela vaut d’être testé.

Serveur web distinct

Utiliser Drupal pour générer des fichiers qui sont ensuite servis par un autre vhost qui est ensuite sécurisé.

Service web

La dernière approche consiste à déplacer les fichiers en dehors du chemin Apache et définir un service web sécurisé plus abouti.

Attacher les dépôts

Ajouter le dépôt

Il s’agit simplement des données de base du fichier composer :

  • vendor
  • nom du projet
  • URL du dépôt

Pas de recherche possible

On aura compris qu’il s’agit d’une approche statique : donc la fonction de recherche disponible sur Drupal.org n’est pas disponible ici.

Uniquement les Tags

Il ne semble pas possible de servir des branches. Ça c’est un peu plus ennuyeux en phase de développement

Cela implique de continuer d’ajouter directement le dépôt dans la partie repositories du fichier composer.json du projet.

L’autre voie a explorer : peut-on “tricher” en utilisant un type basic au lieu d’utiliser un type de serveur Packagist git ?

Au-delà de Drupal

Il s’agit bien de serveurs Packagist. Le pluriel est important.

Il est possible de définir plusieurs serveurs sur la même instance :

  • un serveur pour le domaine principal de l’entreprise pour les briques mutualisées
  • un serveur pour chaque Feature team
  • ou bien des serveurs spécialisés par Stack : Drupal, WordPress, Symfony, PicoCMS, etc.

Un route pour chacun, avec un fichier packages.json spécialisé. De quoi rendre les choses plus lisibles en attendant une approche plus fine servie par un service web à la hauteur des ambitions.