All Projects → everyclass → everyclass-server

everyclass / everyclass-server

Licence: MPL-2.0 license
Web-server microservice of EveryClass

Programming Languages

python
139335 projects - #7 most used programming language
HTML
75241 projects
CSS
56736 projects
javascript
184084 projects - #8 most used programming language
shell
77523 projects
Dockerfile
14818 projects
Mako
254 projects

Projects that are alternatives of or similar to everyclass-server

ncov-csu-edu
A tool to help users check in automatically
Stars: ✭ 42 (-30%)
Mutual labels:  csu
thesisthemeCSU
A template for the thesis of CSU (Central South University).
Stars: ✭ 13 (-78.33%)
Mutual labels:  csu

EveryClass-server

status python version Build Status code-coverage Codacy Badge license

This is the web server part of the EveryClass project.

Communication

If you find any problems with the code please open an issue and provide as much detail as possible. If you wish to discuss the project, you can join our forum (Chinese).

Technology stack

  • Flask: Python web framework
  • PostgreSQL: database
  • uWSGI: WSGI gateway
  • Redis: cache/HyperLogLog

Using the source

  1. Use pipenv sync to build a virtualenv with dependencies installed
  2. Copy everyclass/api_server/config/default.py and name it development.py. Change settings to adjust to your local development environment
  3. Set the environment variable MODE to DEVELOPMENT, then run server.py

Contributions, Bug Reports, Feature Requests

This is an open source project and we would be happy to have contributors who report bugs, file feature requests and submit pull requests. Please report issues here: https://github.com/AdmirablePro/everyclass/issues (not issue tracker of this repository!)

Branch Policy

  • All development goes on the feature/feature-name branch. To commit a change make a pull request or merge to the master branch if you have permission
  • Tagged commits following the pattern vX.X.X will be watched by Travis, our continuous integration tool, which runs unit-tests, builds the Docker image, pushes the image to our private registry and updates services in the staging environment. Tags following the pattern vX.X.X_testing will upgrade the testing environment.
  • Commits should be tested in the staging environment before they are deployed to the production environment.

Contributions Best Practices

Commits

  • Write clear and meaningful git commit messages
  • Make sure your pull request description contains GitHub's special keyword references that automatically close the related issue when merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests)
  • When you make minor changes to a pull request (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) squash your commits afterwards so that you don't have an absurd number of commits for a small fix. (Learn how to squash at https://davidwalsh.name/squash-commits-git )

Feature Requests and Bug Reports

When you file a feature request or submit a bug report to the issue tracker, add the necessary steps to reproduce it. This is very important for weird/rare bugs.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].