Les coulisses du passage en open source de Cap Collectif #4

5 min de lecture.

Si vous n'avez pas encore lu la partie 3, rendez-vous ici.

Dans ce dernier article, nous allons voir les toutes dernières étapes nécessaires au passage en open source.

Choisir la bonne licence

Pour choisir la licence appropriée, nous avons utilisé le site choosealicense.com que je vous recommande, ainsi que les conseils d'avocats spécialisés. Nous avons finalement choisi GNU Affero General Public License v3.0.

La plateforme Cap Collectif utilise de nombreuses briques open source, il était important de vérifier qu’aucune d’entre elles n’utilise une licence qui imposerait à l’ensemble du code d’être distribué sous la même licence.

Il était donc important de vérifier que les licences utilisées par les dépendances étaient compatibles avec notre choix !

Pour les dépendances JavaScript nous avons listé celles-ci à l'aide de :

npx license-checker --summary

Pour les dépendances PHP :

composer licenses -f summary

Nous en avons profité pour supprimer ou rendre open source quelques forks de dépendances que nous utilisions, mais finalement du côté des licences tout était bon !

Il ne faut pas négliger non plus qu'un dépôt open source signifie qu'il est facilement auditable par des personnes malveillantes, il est donc important de s'assurer que les versions des dépendances utilisées soient exemptes de failles de sécurité connues. Dans notre cas nous avons donc utilisé les commandes de vérifications suivantes :

yarn audit
symfony security:check

Si tout est prêt, il suffit alors d'ajouter un fichier .oss/LICENSE au dépôt interne, pour afficher la bonne licence dans le dépôt open source.

Documenter l'installation

Un dépôt open source c'est bien, mais un projet documenté c'est encore mieux !

Nous avons mis en place un site dédié à la documentation avec un guide d'installation complet.

Celui-ci est bien sûr open source et modifiable par tous !

Nous avons utilisé Docusaurus, un outil très pratique pour générer des sites de documentation depuis du Markdown.

Accepter les contributions

Un dépôt open source est prêt et il faut désormais se préparer à accueillir des contributions externes.

Pour cela notre système à 2 dépôts requiert une contrainte très importante à respecter : il ne faut absolument jamais fusionner de PR sur le dépôt open source. À la place on va importer les modifications sur le dépôt interne, qui sera synchronisé vers l'open source.

Pour cela, je vous recommande de protéger la branche principale du dépôt open source, afin d'éviter la mauvaise surprise d'une fusion involontaire…

On effectue toutefois la revue de code des contributions externes sur le dépôt open source, afin de permettre à l'auteur d'effectuer des changements si nécessaire.

Une fois que la PR est acceptée par notre équipe, on effectue les manipulations suivantes :

  • On ajoute .patch à l'url de la PR open source, cela permet d'accéder au patch Git complet, comme ici ;
  • On récupère l'e-mail du contributeur dans le From du patch ;
  • Si c'est un nouveau contributeur, on ajoute dans le dépôt interne son e-mail à l'option authoring_allow_list de la github action .oss-sync.yml afin que l'auteur apparaisse bien en tant qu'auteur des commits ;
  • On importe la PR sur le dépôt interne, avec le script suivant :
# we create a branch in the internal repo
git checkout -b import-my-oss-branch
# we download the patch, at the root
curl -L https://github.com/cap-collectif/cap-collectif/pull/3.patch > patch
# we import the patch
git am < patch
# we remove the download patch
rm patch
# we push the PR to the internal repo
git push

On fusionne la PR sur le dépôt interne et on attend que la synchronisation vers l'open source soit terminée. On peut alors clore la PR du dépôt open source en commentant avec un lien vers le(s) nouveau(x) commit(s) :

Thanks for your contribution !

I have merged it as of https://github.com/cap-collectif/cap-collectif/commit/1a01be7a6292e54f3e6cfb0e63949b9ec057f2d7.

La seule différence avec une fusion classique est que la PR apparaîtra sur l'open source comme fermée, plutôt que fusionnée, comme on peut le voir ici.

Un cas particulier se présente si l'utilisateur modifie un fichier qui provient du dossier .oss du dépôt interne, dans ce cas-là, on adapte le dossier sur lequel appliquer le patch de ces modifications :

git am --directory=.oss < patch

Et voilà, tout est prêt pour le passage en open source !

Publié le