Skip to content

Setting up a local development environment

Jump to bottom
Dr Kim Foale edited this page May 17, 2021 · 1 revision

For local development we use docker-compose so that we don't need to configure postgresql.

  1. git clone https://github.com/geeksforsocialchange/imok.git to download the repository
  2. docker-compose up or make run to launch a postgresql database and the webserver
  3. docker-compose run web python manage.py migrate or make install to run database migrations
  4. docker-compose run web python manage.py createsuperuser or make superuser to create an admin user

You may also want to pip install -r requirements.txt outside of Docker to get code completion in your editor

Internationalisation

You should assume that we need to provide everything in multiple languages and support multiple timezones.

Specifically, you should make all strings translatable though:

from django.utils.translation import gettext as _
myvar = _("A string that a user or administrator will see")
print(myvar)

Testing

Tests are written using BDD in the features directory.

To run the tests:

docker-compose run web python manage.py behave --simple --failfast or make test

We also provide twilio_mock.py for use with manual testing of the Twilio webhooks. It allows you to send a message to the system as follows:

python twilio_mock.py -f +15005550006 -m "NAME alice"

You can also achieve this through an HTTP Post using your favorite client:

curl -X POST --data '{"Body": "NAME alice", "From": "+15005550006"}' localhost:8000/application/twilio

Pull Requests

We encourage contributions and are open to pull requests for improvements to imok.

If you follow the Conventional Commits standard for your commit messages then your PRs will be automatically labeled which helps with the release process, but this isn't a hard requirement.

Once you have submitted any pull request the test suite will automatically run against it. These tests need to pass before your change can be merged, but don't be afraid to raise a PR with broken tests - we can help you make them pass.

Releases

We use Release-Drafter to maintain releases. Repository administrators can see an unpublished release which gets automatically updated with release notes and suggested next version whenever PRs are merged.

A new release can be made at any point by editing the draft release and pressing Publish release.

We use Semantic Versioning for our releases. Release-Drafter should automatically pick a sensible next release version number based on commit messages, but this can be overridden.

Given a version number MAJOR.MINOR.PATCH, releases should increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards compatible manner, and
  • PATCH version when you make backwards compatible bug fixes.
Clone this wiki locally