Contributing Guide
⏱ tutorial time: 20 minutes
This tutorial will help you set up a full Development environment with all components of the isabl
infrastructure.
📘 Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given. isabl
could always use more documentation, whether as part of the README, in doc-strings, or even on the web in blog posts articles, and such. Also, bet you've read the Zen Of Python.
Isabl API
Clone locally:
Build containers:
Create a superuser
Create a superuser with username and password set to admin
(we will need it later):
Start the backend
Now you can login in the frontend at http://localhost:8000 (there won't be much to see). An easy way to create objects is to run the client tests.
Coverage report
Since tests were run inside a container, we need to combine the coverages to see the html report:
Isabl CLI
Clone locally:
Install with pip, it is strongly recommended to install in a virtual environment:
Run tests using tox, make sure you created the admin user:
Or run pytest, pylint or pydocstyle individually:
Note: if your changes depend on a particular branch of Isabl API, make sure both Isabl CLI and Isabl API branches are called the same so that the travis configuration can pick that up.
Isabl Web
Clone locally:
Install yarn:
Install dependencies:
Start the react development server:
Important! export
FRONTEND_URL=localhost:8080
before runningdocker-compose up
in the api repository, note that the port may vary.
Documentation
Simply create a PR in github:
Contribute with Github
Create a branch for local development and get ready to make changes locally:
Commit your changes and push your branch to GitHub (see the emoji reference):
Create a test in:
Submit a pull request through the GitHub website.
Formatting projects
Python Projects are formatted with black. Is required for api
, cli
and apps
, simply run:
Project web
is formatted following the Vue style guide. For this one, simply run:
Bumping version of PyPi
Following the semantic versioning guidelines and update the VERSION
file before creating a PR, for instance:
Emoji reference
We use emojis to quickly categorize commits and pull requests. These are some common type of changes we use but feel free to ignore the conventions:
emoji
name
type of change
🚀
rocket
new feature
🐛
bug
bug fix
📝
memo
changes to documentation
🎨
art
formatting no code change
🔧
wrench
refactoring production code
✅
white_check_mark
adding/editing test logic
👕
shirt
no production code change
💎
gem
bump to new version
Tip: To insert an emoji in mac type control+cmd+space
. Alternative, type the emoji's name within two semicolons (e.g. :rocket:
).
Last updated