README.md

   1 # Migrated to [Codeberg](https://codeberg.org/Inboxen/Inboxen)
   2
   3 This repo is no longer used as we have migrated to Codeberg
   4
   5 Inboxen
   6 =======
   7
   8 [![Tests](https://github.com/Inboxen/Inboxen/actions/workflows/tests.yml/badge.svg)](https://github.com/Inboxen/Inboxen/actions/workflows/tests.yml)
   9 [![Test coverage](http://codecov.io/github/Inboxen/Inboxen/coverage.svg)](http://codecov.io/github/Inboxen/Inboxen)
  10 [![Documentation Status](https://readthedocs.org/projects/inboxen/badge/?version=latest)](https://inboxen.readthedocs.io/en/latest/?badge=latest)
  11
  12 This is the complete system with everything you need to set up Inboxen.
  13
  14 The current maintainer of this repo is [Matt Molyneaux](https://github.com/moggers87)
  15
  16 GPG keys
  17 --------
  18
  19 GPG keys used by Inboxen developers to sign releases:
  20
  21 ```
  22 Matt Molyneaux <moggers87@moggers87.co.uk>
  23     19F5 A8DC C917 FD00 E859   02F4 878B 5A2A 1D47 C084
  24 ```
  25
  26 Security
  27 --------
  28
  29 If you find a security issue with Inboxen, email <security@moggers87.co.uk>. If
  30 you wish to send an encrypted report, then please use key id `0x878B5A2A1D47C084`
  31
  32 Once reported, all security vulnerabilities will be acted on immediately and a
  33 fix with full disclosure will go out to everyone at the same time.
  34
  35 Developing
  36 ----------
  37
  38 You'll need the following tools:
  39
  40 * Git
  41 * Python (we strongly recommend you use virtualenv too)
  42 * PostgreSQL
  43 * NodeJS
  44 * GNU Make
  45 * [EditorConfig](http://editorconfig.org/) *(optional)*
  46
  47 This project comes with a `.editorconfig` file - we recommend installing it to
  48 avoid things like mixing tabs/spaces or accidentally saving files with
  49 DOS-style newlines.
  50
  51 Set yourself up with a virtual environment and run the following:
  52
  53 ```
  54 git clone https://github.com/Inboxen/Inboxen.git
  55 cd Inboxen
  56 make
  57 ```
  58
  59 When you've made your changes, remember to check your code
  60 style and run unit tests.
  61
  62 Python tests:
  63
  64 ```
  65 python manage.py test
  66 ```
  67
  68 JS tests:
  69
  70 ```
  71 npx grunt karma
  72 ```
  73
  74 To check code style on Python:
  75
  76 ```
  77 tox -e isort,lint
  78 ```
  79
  80 And finally, check JS code style:
  81
  82 ```
  83 npx grunt jshint
  84 ```
  85
  86 ### Local HTTP server
  87
  88 You'll need a `inboxen.config` file, for example:
  89
  90 ```
  91 secret_key: some_random_string
  92 debug: true
  93 tasks:
  94   always_eager: true
  95 ```
  96
  97 If you want to start a local HTTP server to test out your changes, run the following:
  98
  99 ```
 100 python manage.py runserver
 101 ```
 102
 103 You can connect to it on <http://localhost:8000/>.
 104
 105 With `debug=true`, you'll have the Django Debug Toolbar enabled and you can
 106 find the Inboxen styleguide at <http://localhost:8000/styleguide>
 107
 108 ### Pinned Dependencies
 109
 110 Inboxen uses `pip-tools` to help manage its dependencies. The direct
 111 requirements of Inboxen are kept in `requirements.in` and then we use the
 112 following command to pin the entire dependency graph:
 113
 114 ```
 115 pip-compile --upgrade --output-file requirements.txt requirements.in
 116 ```
 117
 118 The resulting `requirements.txt` can be installed to a clean virtualenv with
 119 `pip` to get the exact package versions that Inboxen uses in production. You
 120 can also use the `pip-sync` (which comes with `pip-tools`) to update an
 121 existing virtualenv as well as remove packages that are no longer required.
 122
 123 The same principal applies to `requirements-dev.txt`/`requirements-dev.txt` and
 124 any files found in `extras/requirements`.
 125
 126 If for any reason you wish to bypass pinning dependencies, `requirements.in`
 127 and `requirements-dev.in` are in the format expected by `pip`.
 128
 129 Committing and Branching
 130 ------------------------
 131
 132 ### Branching
 133
 134 All development happens in branches off of `main`. Each branch should have an
 135 associated issue - if there isn't one for what you're working on then create a
 136 new issue first!
 137
 138 Branch names should be of the format `<issue>-<description>` where:
 139
 140 * `<issue>` is the issue you are working on
 141 * `<description>` is a brief description of what's happening on that branch
 142
 143 For example, `129-pin-inboxes` was the branch used for implementing the [pin
 144 inbox feature](https://github.com/Inboxen/Inboxen/issues/129)
 145
 146 Finished branches are then merged into `main`. If there is someone available
 147 to review your branch, your branch should be reviewed and merged by them.
 148 Remember to add a note to CHANGELOG.md when merging!
 149
 150 #### Hotfix branches
 151
 152 Hotfixes should be branched from the latest deploy tag, and then be tagged
 153 themselves as a normal deployment before being merged back into `main`.
 154
 155 ### Commit messages
 156
 157 You should follow the pattern of "summary, gap, details, gap, issue references"
 158
 159 For example:
 160
 161 ```
 162 Blah blah thing
 163
 164 Fixes this thing, changes how we should do something else
 165
 166 fix #345
 167 touch #234
 168 ```
 169
 170 If you are committing on `main`, then make sure to end your commit message
 171 with "IN MAIN" so we know who to blame when stuff breaks.