A containerized gitolite server with a django frontend.
Giz attempts to build on the following design: 0. The webserver dictates the state of the gitolite server.
- The gitolite server operates independently of the webserver.
- Everything triggered through the webserver, can also be triggered through gitolite.
The name is pronounced like "gits", like "git" in plural.
- Create Alpine image
- Setup gitolite
- Mount project
- Run django
- Fix gitolite configuration file
We need to include user configuration files by adding
include "*.conf"or something similar. Preferrably add them in a subdirectory, eihterconf/users/andconf/organizationsrespectively. - Setup prod environment
- Setup gunicorn
- Setup nginx
- Make django app production ready
- Get secrets from variables
- Also in docker
- Setup gitolite hooks to invalidate redis cache on push
- Buy domain
- Update documentation
- Modularize the whole thing
- Git-to-giz communication should be a single module.
- Git-to-giz module should always accept status of gitolite as the truth.
- Git-to-giz module should be able to import all repositories (and users,
assuming they're "well formed", ie.
user/repo) from disk/git. - In case of "missing users", they should be created, and site admin should be
able to manage said users (set mail, send password reset, etc.).
- Bonus feature: look for GPG signed commits in repos that contain the users email address.
- Repo viewer should be its own module.
- The pull requests should be in this module.
- repo preferences / settings should also live here.
- Issues, CI/CD, documentation, releases, analytics should all be in their own modules.
- Developer environment
- We should automatically populate the environment with users, repos, and other
modules when
DEBUG=True
- Frontend should have streamlined buttons, forms, (flex) containers et. al.
- SCSS?
For a list of features that are planned, see TODO.md
TODO: Steps for production deployment.
For running a local development environment
0. Setup credentials source ./setupenv