Modularized platform for Bitrock internal use.
- GitHub Repository
- Board
- Wiki
- Supabase Dashboard
- env variables on Notion (ask Davide Ghiotto for access)
git clone [email protected]:bitrockteam/bitrock-center.git
- See env variables on dedicated notion page (ask Davide Ghiotto for access)
- Copy
apps/backend/.env.example
toapps/backend/.env
file and update the values accordingly. - Copy
apps/frontend/.env.example
toapps/frontend/.env
file and update the values accordingly. - Copy
packages/db/.env.example
topackages/db/.env
file and update the values accordingly. - Copy
.env.example
to.env
file and update the values accordingly.
Beware that you will need to run the local instance of Supabase to obtain these two:
NEXT_PUBLIC_SUPABASE_ANON_KEY
andSUPABASE_PROJECT_KEY
. Keep reading to understand how to get them.
- install the supabase cli (optional): if not installed a prefix
npx
is required to run the supabase via command line - run
supabase login
to access the hosted supabase instance - run
supabase link
to link the local instance to the remote one (for database diff, migrations and other stuff) - run
supabase start
will start a docker container for your local supabase instance
If everything run correctly you should see something like this on your terminal:
Started supabase local development setup.
API URL: http://localhost:54321
DB URL: postgresql://postgres:postgres@localhost:54322/postgres
Studio URL: http://localhost:54323
Inbucket URL: http://localhost:54324
anon key: eyJh......
service_role key: eyJh......
In the console you will see the "anon" and "service_role" keys displaying two tokens. These are respectively the values of
apps/frontend/.env > NEXT_PUBLIC_SUPABASE_ANON_KEY
andapps/backend/.env > SUPABASE_PROJECT_KEY
.
Access the studio at http://localhost:54323.
To stop the container just run supabase stop
.
supabase db pull
to download locally the remote configuration along with the schemasupabase db dump -f supabase/seed.sql --data-only
to download only the data available in the remote instanceWarning: do not commit
supabase/seed.sql
file since it contains data from the authentication of the users. First we need to exclude this data from the local dumpsupabase migration up
to apply the new migrationssupabase db reset
to reset the local instance and restarting it applying the new schema and seed data from the remote updates
This procedure will automatically apply the migrations.
- create a migration with
supabase db diff -f <your-migration-name>
- locally test that running
supabase db reset
will manage correctly the migration - when all checks are done (and maybe after releasing in develop/main branch) run the
supabase db push
command to push your local changes to the remote instance
The push
command will not reset the data on the remote instance.
nvm install
(ornvm use
if you have already installed the version written in.nvmrc
file)corepack enable
yarn
yarn build
yarn dev
:- frontend on
localhost:3000
- frontend on
We are going to use github flow
as branching
strategy.
- feature branch:
feat/<issue-number>-branch-summary-here
-> e.g. (5-users-management) - bug branch:
bug/<issue-number>-branch-summary-here
Issue states:
- to do
- in progress
- pull requested
- dev released
- done
- Conventional Commit: check commit message format with standard format
- Pre-commit checks with husky: check linting & commit message format
We cannot merge directly in main
and we will require the pipelines to pass.