Contribuer au code#
Cette page explique comment vous pouvez contribuer au code du projet.
Voir aussi
Les règles de codage sont présentées dans la page Règles de codage.
Forker le projet#
La première étape est de forker le projet sur GitHub. Vous pouvez le faire en visitant le projet DataLab et en cliquant sur le bouton « Fork » en haut à droite de la page GitHub du projet.
Une fois que vous avez forké le projet, vous aurez une copie du projet dans votre propre compte GitHub. Ensuite, vous pouvez cloner le projet sur votre ordinateur et commencer à travailler dessus.
Soumettre une pull request#
Dès que vous avez apporté des modifications, vous pouvez soumettre une pull request au projet original. Pour ce faire, allez sur votre projet forké sur GitHub et cliquez sur le bouton « Pull request » en haut à droite de la page.
Ensuite vous devrez remplir un formulaire pour décrire votre pull request. Une fois que vous avez soumis la pull request, les mainteneurs du projet examineront vos modifications et les fusionneront s’ils sont satisfaits.
Lors du processus de revue, les mainteneurs du projet vérifieront que votre code suit les règles de codage et qu’il ne casse pas les tests existants. Si votre code ne suit pas les directives de codage, vous devrez le corriger avant que votre pull request puisse être fusionnée.
Tâches de mainteneur#
Quelques tâches de maintenance ne sont volontairement pas exécutées par la CI de release et doivent être effectuées localement sur un poste Windows par un mainteneur du projet. Elles produisent des fichiers versionnés que la CI consomme ensuite tels quels.
Rafraîchir les captures d’écran de la documentation#
Les fichiers PNG sous doc/images/ sont versionnés. Ils sont régénérés en lançant DataLab et en capturant ses dialogues / panneaux — une étape qui nécessite une véritable session de bureau (le runner CI sous Xvfb se fige au démarrage de l’interface DataLab et le rendu dépend des polices et du thème du système, ce qui le rend non-déterministe d’un runner à l’autre).
Le pipeline de capture produit des fichiers par langue (foo.fr.png / foo.en.png) grâce à la configuration figure_language_filename de Sphinx. Les sources RST référencent le nom sans suffixe (foo.png) ; chaque build de langue sélectionne automatiquement le suffixe correspondant lorsqu’il est disponible et retombe sur le fichier non suffixé sinon.
À relancer dès qu’une modification affecte le rendu de l’interface (menus, dialogues, panneaux, thèmes) :
scripts\update_screenshots.bat
ou via la tâche VS Code 🖼️ Refresh doc screenshots. Validez les PNGs nouveaux ou mis à jour sous doc/images/shots/ dans un commit dédié (par exemple docs: refresh screenshots). Dès qu’une paire foo.fr.png + foo.en.png existe pour une capture donnée, le fichier non suffixé foo.png n’est plus utilisé que comme repli et pourra être supprimé dans un commit de nettoyage ultérieur.
Régénérer les ressources graphiques#
L’icône de l’application (resources/DataLab.ico) et les bitmaps de l’installeur WiX (wix/dialog.bmp, wix/banner.bmp) sont générés à partir de sources SVG. À relancer uniquement quand les sources SVG changent :
scripts\build_resources.bat
ou via la tâche VS Code 🎨 Generate resources.