Django application with browsable API and OpenAPI to request and view statistics of the 3D printer from BambuLab.
- Python 3.13
- uv
- PostgreSQL 18
- Django 6.0.7
-
Create a virtual environment using uv:
uv venv --allow-existing # Windows .venv\Scripts\activate # Linux: source .venv/bin/activate uv sync
-
Create a database in your PostgreSQL instance
-
Create a
.envfile according to the.env.examplefile. The connection details for the printer (PRINTER_) can be taken from the Printer display and BambuStudio:- PRINTER_IP_ADDRESS: IP address of the printer from the Printer display: Settings (3rd symbol) → WLAN → IP
- PRINTER_ACCESS_CODE: Access code can be taken from the Printer display: Settings (3rd symbol) → WLAN → Access Code
- PRINTER_SERIAL: Serial can be seen in BambuStudio → Device tab → Model: Bambu Lab P1S → Serial
-
Run the development server:
python manage.py runserver # or uv run manage.py runserver -
Load migrations
uv run manage.py migrate
-
Install pre-commit hooks:
pre-commit install
-
Load fixture for Django admin interface theme
uv run manage.py loaddata admin_interface_theme_singularIT.json
-
Start QCluster
uv run .\manage.py qcluster
If you wanna see the web app functionalities without being able or willing to connect to a printer, you can create fake data using the seeder.
uv run .\manage.py seedGitLab CI/CD is a continuous integration and continuous deployment service built into GitLab. It automates tasks like testing, building, and deploying code on every push or merge request. Pipelines are defined in a .gitlab-ci.yml file at the repository root. Additional configuration can be modularized in the .gitlab folder for better organization:
.gitlab/
├── ci/
│ ├── lint.yml
│ ├── test.yml
│ └── deploy.yml
.gitlab-ci.yml
To track vulnerabilities in dependencies we are using our Dependency Track Dashboard. The dashboard is updated with every push to the default branch or a created tag.
The dashboard is updated with the help of the uv.lock file that is generated by uv.
You can view our Dependency Track Dashboard here.
In the lint stage we are running pre-commit that checks for code formatting and linting issues.
When? Each push to a protected branch or a branch that has an open merge request to a protected branch.
In general our test stage has 2 jobs:
django-test- runs the django unit testsdeploy-check- runs the django deployment check for security issues
When? Each push to a protected branch or a branch that has an open merge request to a protected branch.
When? Each push to a protected branch.
This is a personal learning project and is not open to contributions. Thank you for your understanding.
The project idea and technical support was provided by singularIT in the frame of an internship.