generated from devjonatas/axum-template
Pixie log the backlog api
- Rust 78.3%
- HTML 11.6%
- Hurl 7.3%
- PLpgSQL 0.9%
- CSS 0.9%
- Other 1%
O clippy-strict quebrou compilando tinyvec 1.13.0:
error: cannot find macro `vec` in this scope
--> tinyvec-1.13.0/src/tinyvec.rs:710:21
error: could not compile `tinyvec` (lib) due to 1 previous error
A causa nao e o tinyvec. O .gitignore trazia, desde o `cargo new`, o
bloco padrao com `Cargo.lock` ignorado e o comentario "Remove Cargo.lock
from gitignore if creating an executable" logo acima -- e este crate
produz um executavel ([[bin]] pixie-api), nao uma biblioteca.
Sem o lock no repositorio, cada step do CI resolvia as dependencias do
zero ("Locking 479 packages to latest Rust 1.90 compatible versions") e
pegava o que estivesse publicado naquele minuto. Deu tinyvec 1.13.0, que
nao compila em 1.90. Localmente nada quebrava porque o lock existe no
disco e prende tinyvec em 1.11.0. Qualquer publicacao no crates.io podia
quebrar o build sem um unico commit nosso -- e a montante ainda estava a
janela de supply chain que um lock fecha.
Passa a versionar o Cargo.lock e adiciona --locked a build, test, clippy,
doc e release. Com --locked um lock defasado falha alto, com mensagem
clara, em vez de o cargo re-resolver em silencio.
Verificado com a mesma toolchain do CI (rustc 1.90.0, 1159e78c4):
cargo clippy --locked --all-targets -- -D warnings passa sem achados.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LFXVuu81dmPP2U1q4YLFHT
|
||
|---|---|---|
| .cargo | ||
| .githooks | ||
| .sqlx | ||
| .woodpecker | ||
| migrations | ||
| scripts | ||
| src | ||
| static | ||
| templates | ||
| test-results | ||
| tests | ||
| .audit.toml | ||
| .buildpacks | ||
| .env.example | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| app.json | ||
| Cargo.lock | ||
| Cargo.toml | ||
| debug_render.sh | ||
| docker-compose.yml | ||
| Dockerfile | ||
| fix_migration.sql | ||
| init_db.sh | ||
| LICENSE | ||
| parse_lcov.py | ||
| Procfile | ||
| README.md | ||
| rust-toolchain | ||
Pixie API
A Rust-based API for Pixielog, featuring Keyrunes authentication, email confirmation, and Femtocat-styled views.
Prerequisites
- Rust (latest stable)
- Docker and Docker Compose
- Postgres client (optional, for debugging)
Configuration
The application requires the following environment variables. A .env file can be used locally.
| Variable | Description | Example |
|---|---|---|
DATABASE_URL |
Postgres connection string | postgres://postgres:password@localhost:5432/pixielog |
SMTP_URL |
SMTP server URL | smtp://localhost:1025 |
KEYRUNES_URL |
Keyrunes service URL | http://localhost:3000 (internal) or http://keyrunes:3000 (docker) |
APP_URL |
Public URL of this app | http://localhost:8000 |
Running the Application
1. Start Infrastructure
Start Postgres, Mailhog, and Keyrunes using Docker Compose:
docker-compose up -d
2. Initialize Keyrunes (First Run Only)
Setup superuser and organization in Keyrunes:
docker compose exec keyrunes sh /setup.sh
3. Run Database Migrations
Initialize the pixielog database schema:
sqlx migrate run
3. Run Locally (Development)
Start the API server:
cargo run
The server will be available at http://localhost:8000.
4. Run via Docker
To run the entire stack including the API in Docker (if a Dockerfile is provided, otherwise mostly used for deps):
docker-compose up -d
(Note: Ensure your config or env vars point to the keyrunes container name if running inside docker network)
Development
View Docs
Swagger UI is available at: http://localhost:8000/swagger-ui/
Running Tests
Run unit and integration tests:
# Unit tests
cargo test
# Hurl Integration tests (requires running server)
hurl --test tests/auth.hurl