Two repos, one goal !

When I was a child, my mother used to tell nice bedtime stories. My favorite one was the The Tale of Two Repos. It goes like this :

"Once upon a time, in the CdeP, a little core.dashboards_store repo was born. The repo tried very hard to provide ETLs for all the schoolboards at once. But the schoolboards were many and the SQL capabilites to retrofit itself to a schoolboard's context were few. So the core.dashboards_store repo decided to split itself into many little repos, one for each schoolboard. And the cssXX.dashboard_store repo was born. And the cssXX.dashboards_store repo was granted the power to override anything from core.dashboards_store. And the core.dashboards_store repo was happy. And the cssXX.dashboards_store repo was happy. And the CdeP was happy. And they all merged develop into master happily ever after."

The moral of the story is that the core.dashboards_store repo is the parent repo of all of the cssXX.dashboards_store repos. The core.dashboards_store repo contains all the ETLs that are common to all of the CSS. The cssXX.dashboards_store repo contains everything that is specific to cssXX, including, if needed, some SQL files overriding the ones in the core.

If you have already been exposed to Object-Oriented Programing, the core.dashboards_store repo is the parent class providing overridable methods, and the cssXX.dashboards_store repo is the child class, that might want to override some of the parent's methods.

You will ALWAYS need two repos to work with the core_dashboards_store. The core.dashboards_store containing everything that is shared between the schoolboards, and your own custom cssXX.dashboards_store implementing what can't be shared, such as the way to identify students enrolled in an adapted program.
When integrating the store to your schoolbard, all modifications you do (overriding, enabling, implementing an adapter, populating a seed), schould take place from inside the cssXX.dashboards_store repo. The core.dashboards_store repo schould never be modified as it is shared between all the schoolboards.

Cloning the repo

The two repos are to be cloned in the same directory, the <working directory> of your choice. If not, you will have to change the cssXX.dashboards_store/packages.yaml to reflect the new path.
You will need to create a github account and add your SSH key to your account. If you don't have one, you can follow this guide to create one. Make sure to follow the Linux instructions if you are using either WSL2 or Linux server. Don't forget to add you ssh key as explained here : Adding a new SSH key to your GitHub account. If you don't know how to create an SSH with ubuntu, check here : Generating a new SSH key

Bootstraping a working dashboards Store

In order to clone the repo through SSH, you will need a properly set-up github account. Your local public key must be added to your Github account. If you don't have one, you can follow this guide to create one. Make sure to follow the Linux instructions if you are using either WSL2 or Linux server.
  1. Start by cloning the Core : (You'll need a properly set up github account with an SSH key).
git clone git@github.com:Sciance-Inc/core.dashboards_core_dashboards_store.git
  1. Checkout the master branch to get the last template revision
git checkout master
  1. Create a Poetry / Virtualenv from the Core. This will install every Python packages you need, including DBT.
cd core.dashboards_store
eval $(poetry env activate)
poetry install --no-root  # The --no-root might not be needed, depending of your Poetry's version [#38](https://github.com/Sciance-Inc/core.dashboards_store/issues/38)
  1. Bootstrap a new cssXX.dashboards_store repo from the Core's template
    You will be prompted for informations
cd ../
cookiecutter core.dashboards_store/tooling/template
  1. Let's follow the best practices and use git to the repo you have just created
git init
git remote add origin <your remote's url>
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. Go read the cssXX.dashboards_store/README.md to learn more about the post-configurations steps required to have everything working.

What did I just do ?

If everyhting worked well, you schould have the following directory structure :

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

Both subfolders schould contains git-ready DBT projects.

Starting from now, <working directory> will always design the path to the folder containing the two repos (unless mentioned otherwise)
Edit this page on GitHub