Installation

L'histoire de deux repos

Deux repos, un objectif!

Quand j'étais enfant, ma mère me racontait de belles histoires avant de dormir. Ma préférée était L'histoire de deux repos. Elle allait comme ceci:

"Il était une fois, dans la CdeP, un petit repo core.dashboards_store. Le repo essayait très fort de fournir des ETL pour tous les centres de services scolaires en même temps. Mais les centres étaient nombreux, et les capacités SQL pour s'adapter à chaque contexte étaient limitées. Le repo core.dashboards_store décida donc de se diviser en plusieurs petits repos, un par centre de services scolaire. Ainsi naquit le repo cssXX.dashboards_store. Ce repo reçut le pouvoir d'override n'importe quoi provenant de core.dashboards_store. Le repo core.dashboards_store était heureux. Le repo cssXX.dashboards_store était heureux. La CdeP était heureuse. Et ils fusionnèrent tous develop dans master pour toujours."

La morale de l'histoire est que le repo core.dashboards_store est le repo parent de tous les repos cssXX.dashboards_store. Le repo core.dashboards_store contient tous les ETL communs à l'ensemble des CSS. Le repo cssXX.dashboards_store contient tout ce qui est spécifique au CSS cssXX, y compris, au besoin, certains fichiers SQL qui remplacent ceux du core.

Si vous connaissez déjà la programmation orientée objet, le repo core.dashboards_store est la classe parent qui fournit des méthodes surchargeables, et le repo cssXX.dashboards_store est la classe enfant qui peut vouloir surcharger certaines méthodes du parent.

Vous aurez TOUJOURS besoin de deux repos pour travailler avec core.dashboards_store: le repo core.dashboards_store, qui contient tout ce qui est partagé entre les centres de services scolaires, et votre repo personnalisé cssXX.dashboards_store, qui implémente ce qui ne peut pas être partagé, par exemple la manière d'identifier les élèves inscrits à un programme adapté.
Lorsque vous intégrez le Store dans votre centre de services scolaire, toutes vos modifications (overriding, activation, implémentation d'un adapter, alimentation d'une seed) doivent être faites depuis le repo cssXX.dashboards_store. Le repo core.dashboards_store ne devrait jamais être modifié, puisqu'il est partagé par tous les centres.

Cloner les repos

Les deux repos doivent être clonés dans le même dossier, soit le <working directory> de votre choix. Sinon, vous devrez modifier cssXX.dashboards_store/packages.yaml pour refléter le nouveau chemin.
Vous devrez créer un compte GitHub et y ajouter votre clé SSH. Si vous n'en avez pas, suivez ce guide. Assurez-vous de suivre les instructions Linux si vous utilisez WSL2 ou un serveur Linux. N'oubliez pas d'ajouter votre clé SSH comme expliqué ici: Ajouter une nouvelle clé SSH à votre compte GitHub. Si vous ne savez pas comment créer une clé SSH avec Ubuntu, consultez: Generating a new SSH key

Initialiser un Dashboards Store fonctionnel

Pour cloner le repo en SSH, vous aurez besoin d'un compte GitHub correctement configuré. Votre clé publique locale doit être ajoutée à votre compte GitHub. Si vous n'en avez pas, suivez ce guide. Assurez-vous de suivre les instructions Linux si vous utilisez WSL2 ou un serveur Linux.
  1. Commencez par cloner le Core; vous aurez besoin d'un compte GitHub configuré avec une clé SSH.
git clone git@github.com:Sciance-Inc/core.dashboards_store.git
  1. Basculez sur la branche master pour obtenir la dernière révision du template.
git checkout master
  1. Créez un environnement Poetry / Virtualenv depuis le Core. Cela installera tous les paquets Python nécessaires, y compris dbt.
cd core.dashboards_store
eval $(poetry env activate)
poetry install --no-root  # --no-root peut ne pas être requis selon votre version de Poetry [#38](https://github.com/Sciance-Inc/core.dashboards_store/issues/38)
  1. Initialisez un nouveau repo cssXX.dashboards_store à partir du template du Core.
    Quelques informations vous seront demandées.
cd ../
cookiecutter core.dashboards_store/tooling/template
  1. Suivons les bonnes pratiques et utilisons Git pour le repo que vous venez de créer.
git init
git remote add origin <url_de_votre_depot_distant>
git add .
git commit -m "feat: one commit to initiate them all, one commit to rule them all, one commit to bring them all and in the gitness bind them, in the land of GitHub where the bugs lie."
git push -u origin master
  1. Lisez cssXX.dashboards_store/README.md pour en savoir plus sur les étapes de post-configuration nécessaires au bon fonctionnement du projet.

Qu'est-ce que je viens de faire?

Si tout s'est bien passé, vous devriez obtenir la structure de dossiers suivante:

<working directory>
├── core.dashboards_store
└── cssXX.dashboards_store

Les deux sous-dossiers devraient contenir des projets dbt prêts pour Git.

À partir de maintenant, <working directory> désignera toujours le chemin du dossier contenant les deux repos, sauf mention contraire.
Copyright © 2026