Skip to content
Web-server microservice of EveryClass
Python HTML CSS JavaScript Other
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
calendar_files
deploy
everyclass
frontend
tests
.codecov.yml
.flake8
.gitattributes
.gitignore
.gitmodules
.python-version
.travis.yml
CHANGELOG
Dockerfile
LICENSE
Pipfile
Pipfile.lock
README.md
reload
server.py

README.md

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.

You can’t perform that action at this time.