commitz

by marcosflp

GitHub Readme.md

CommitZ

Running

Setup

  • Inside the backend folder, do the following:
  • Create a copy of commitz/settings/local.py.example:
     cp commitz/settings/local.py.example commitz/settings/local.py
  • Create a copy of .env.example: cp .env.example .env
  • Inside the .env file add your GitHub APP Client ID in SOCIAL_AUTH_GITHUB_KEY
  • Inside the .env file add your GitHub Client Secret in SOCIAL_AUTH_GITHUB_SECRET

If you are using plain python:

  • Create the migrations for users app: python manage.py makemigrations
  • Run the migrations: python manage.py migrate

If you are using docker:

  • Create the migrations for users app:
    docker-compose run --rm backend python manage.py makemigrations
  • Run the migrations: docker-compose run --rm backend python manage.py migrate

Tools

Running the project (without docker)

  • Open a command line window and go to the project's directory.
  • pip install -r requirements.txt && pip install -r dev-requirements.txt
  • npm install
  • npm run start
  • Open another command line window and go to the backend directory.
  • workon theprojectname or source theprojectname/bin/activate depending on if you are using virtualenvwrapper or just virtualenv.
  • python manage.py runserver

Running the project (with docker)

  • Open a command line window and go to the project's directory.
  • docker-compose up -d To access the logs for each service run docker-compose logs -f service_name (either backend, frontend, etc)

Celery

  • Open a command line window and go to the project's directory
  • workon theprojectname or source theprojectname/bin/activate depending on if you are using virtualenvwrapper or just virtualenv.
  • python manage.py celery

Testing

make test

Will run django tests using --keepdb and --parallel. You may pass a path to the desired test module in the make command. E.g.:

make test someapp.tests.test_views

Adding new pypi libs

Add the libname to either requirements.in or dev-requirents.in, then either upgrade the libs with make upgrade or manually compile it and then, install. pip-compile requirements.in > requirements.txt or make upgrade pip install -r requirements.txt

Deployment

Setup

This project comes with a app.json file for heroku, that can be used to create an app on heroku from a GitHub repository.

After setting up the project, you can init a repository and push it on GitHub. If your repository is public, you can use the following button:

Deploy

If you are in a private repository, access the following link replacing $YOUR_REPOSITORY_LINK$ with your repository link.

  • https://heroku.com/deploy?template=$YOUR_REPOSITORY_LINK$

Remember to fill the ALLOWED_HOSTS with the URL of your app, the default on heroku is appname.herokuapp.com. Replace appname with your heroku app name.

Sentry

Sentry is already set up on the project. For production, add SENTRY_DSN environment variable on Heroku, with your Sentry DSN as the value.

You can test your Sentry configuration by deploying the boilerplate with the sample page and clicking on the corresponding button.

Sentry source maps for JS files

The bin/post_compile script has a step to push Javascript source maps to Sentry, however some environment variables need to be set on Heroku.

You need to enable Heroku dyno metadata on your Heroku App. Use the following command on Heroku CLI:

  • heroku labs:enable runtime-dyno-metadata -a <app name>

The environment variables that need to be set are:

After enabling dyno metadata and setting the environment variables, your next Heroku Deploys will create a release on Sentry where the release name is the commit SHA, and it will push the source maps to it.

Linting

  • Manually with prospector and npm run lint on project root.
  • During development with an editor compatible with prospector and ESLint.

Pre-commit hooks

  • Run pre-commit install to enable the hook into your git repo. The hook will run automatically for each commit.
  • Run git commit -m "Your message" -n to skip the hook if you need.

Opinionated Settings

Some settings defaults were decided based on Vinta's experiences. Here's the rationale behind them:

CELERY_ACKS_LATE = True

We believe Celery tasks should be idempotent. So for us it's safe to set CELERY_ACKS_LATE = True to ensure tasks will be re-queued after a worker failure. Check Celery docs on "Should I use retry or acks_late?" for more info.

Commercial Support

This project, as other Vinta open-source projects, is used in products of Vinta clients. We are always looking for exciting work, so if you need any commercial support, feel free to get in touch: contact@vinta.com.br

Copyright (c) 2018 Vinta Serviços e Soluções Tecnológicas Ltda. MIT License