Déplacer un plugin vers son propre dépôt¶

Contents

Étapes d’extraction d’un plugin
Nettoyage du noyau Elgg

Étapes d’extraction d’un plugin ¶

Déplacez le code vers son propre dépôt ¶

Suivez le guide Github pour transformer un sous-dossier en un nouveau dépôt (Splitting a subfolder out into a new repository). Ceci va faire en sorte que l’historique des commits soit préservé.

Dépendances ¶

Si le plugin a des dépendances sur n’importe quelles bibliothèques externes, assurez-vous que ces dépendances soient gérées. Par exemple, si une bibliothèque PHP est requise qui est livrée avec le noyau d’Elgg, assurez-vous de l’ajouter dans le composer.json de ce plugin dans la mesure où vous ne pouvez pas vous appuyer sur le fait que le noyau d’Elgg conserve cette bibliothèque.

Commitez le code ¶

Au cours du guide GitHub un nouveau dépôt est créé pour le plugin que vous essayez de déplacer.

Dans la mesure où une tentative a déjà été faite pour extraire certains des plugins vers leur propre dépôt il se peut que le dépôt existe déjà.

Si le dépôt n’existait pas pour le plugin, assurez-vous que vous le créez dans Elgg organisation.

Si le dépôt existe déjà, le meilleur moyen de mettre à jour le code serait en faisant une Pull Request. Ceci risque cependant probablement d’échouer à cause d’une différence dans la manière dont le dépôt a été initialement créé (comme discuté dans Problème avec GitHub).

Les dépôts initiaux ont été créés avec

git subtree split

et le guide appelle

git filter-branch --prune-empty --subdirectory-filter

Ceci va laisser une différence dans les commits que Github est incapable de résoudre. Dans ce cas vous devrez forcer un push des modifications vers le dépôt du plugin Elgg existant.

Avertissement

Dans la mesure où cela va réécrire tout l’historique du dépôt du plugin, assurez-vous que vous savez que c’est bien ce que vous souhaitez faire.

Packagist ¶

Assurez-vous que le composer.json du plugin contient bien toutes les informations pertinentes. Voici un exemple :

{
        "name": "elgg/<name of the repository>",
        "description": "<a description of the plugin>",
        "type": "elgg-plugin",
        "keywords": ["elgg", "plugin"],
        "license": "GPL-2.0-only",
        "support": {
                "source": "https://github.com/elgg/<name of the repository>",
                "issues": "https://github.com/elgg/<name of the repository>/issues"
        },
        "require": {
                "composer/installers": ">=1.0.8"
        },
        "conflict": {
                "elgg/elgg": "< <minimal Elgg required version>"
        }
}

La règle conflict est ici pour aider à éviter l’installation de ce plugin dans une version d’Elgg non supportée.

Ajoutez le dépôt à Packagist, pour les dépôts existants ceci a déjà été fait. Assurez-vous que Packagist est mis à jour correctement avec tous les commits.

Tagguer une release ¶

Afin que Composer soit capable de mettre en cache le plugin pour une installation plus rapide, une release doit être créée sur le dépôt. A priori, la première version qui doit être tagguée est la même version que celle mentionnée dans le manifest.xml. Après cela le développement peut commencer, suivi par le schéma de version Semver.

Traductions ¶

Si les traductions pour le plugin doivent être gérées par Transifex, ajoutez le plugin à Transifex.

Nettoyage du noyau Elgg ¶

Maintenant que le plugin a été déplacé dans son propre dépôt, il est temps de faire une Pull Request sur le noyau d’Elgg pour supprimer le code originel.

Supprimez le plugin ¶

Supprimez le plugin du dossier mod
Recherchez le nom du plugin dans le noyau pour trouver toute référence qui aurait également besoin d’être retirée (par ex. anciennes docs, tests spéciaux, etc.)

Déplacer un plugin vers son propre dépôt¶

Étapes d’extraction d’un plugin ¶

Déplacez le code vers son propre dépôt ¶

Dépendances ¶

Commitez le code ¶

Packagist ¶

Tagguer une release ¶

Traductions ¶

Nettoyage du noyau Elgg ¶

Supprimez le plugin ¶

Traductions ¶

Plugins joints ¶

Composer ¶

Documentation ¶