feat: add Python Project Template and TimeNet CLI projects
CI/CD Pipeline / Build & Deploy (push) Failing after 21s
CI/CD Pipeline / Build & Deploy (push) Failing after 21s
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Python Project Template"
|
||||
description: "Opinionated Python project template with modern tooling: uv, ruff, mypy, pytest, Docker, and CI/CD ready"
|
||||
pubDate: 2026-05-01
|
||||
status: "active"
|
||||
stack: ["Python", "Docker", "Gitea Actions", "Portainer"]
|
||||
featured: true
|
||||
---
|
||||
|
||||
# Python Project Template
|
||||
|
||||
An opinionated Python project template designed for rapid development with modern tooling and infrastructure-as-code practices.
|
||||
|
||||
## Features
|
||||
|
||||
- **Modern Python tooling**: uv for fast dependency management, ruff for linting, mypy for type checking
|
||||
- **Testing**: pytest with coverage reports
|
||||
- **Docker ready**: Multi-stage Dockerfile optimized for Python projects
|
||||
- **CI/CD pipeline**: Gitea Actions workflows for automated testing and deployment
|
||||
- **Portainer integration**: Deploy to self-hosted infrastructure with one push
|
||||
- **Development environment**: nox for task automation
|
||||
|
||||
## Why I Built This
|
||||
|
||||
After setting up multiple Python projects from scratch, I noticed I was repeating the same patterns: uv for dependencies, ruff for code quality, Docker for deployment, Gitea Actions for CI/CD. Each time I'd spend hours configuring these tools.
|
||||
|
||||
This template captures those decisions so new projects start with production-ready infrastructure on day one.
|
||||
|
||||
## Stack
|
||||
|
||||
- **Python 3.12+** with uv package manager
|
||||
- **Quality tools**: ruff (linting), mypy (type checking), pytest (testing)
|
||||
- **Containerization**: Docker with multi-stage builds
|
||||
- **CI/CD**: Gitea Actions with automated testing and deployment
|
||||
- **Orchestration**: Portainer stack deployment
|
||||
|
||||
## Use Cases
|
||||
|
||||
Perfect for:
|
||||
- Web APIs (FastAPI, Flask)
|
||||
- CLI tools
|
||||
- Background workers
|
||||
- Self-hosted applications
|
||||
|
||||
## Status
|
||||
|
||||
Active and maintained. I use this template for all new Python projects.
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "TimeNet CLI"
|
||||
description: "Command-line tool for managing TimeNet attendance tracking - clock in/out from terminal"
|
||||
pubDate: 2026-04-15
|
||||
status: "active"
|
||||
stack: ["Python", "CLI", "Automation"]
|
||||
featured: false
|
||||
---
|
||||
|
||||
# TimeNet CLI
|
||||
|
||||
A command-line interface for managing TimeNet attendance tracking. Clock in, clock out, and check status without opening the web interface.
|
||||
|
||||
## What It Does
|
||||
|
||||
TimeNet CLI automates daily time tracking workflows:
|
||||
- Clock in/out with a single command
|
||||
- Check current status (in/out, hours worked today)
|
||||
- View work history
|
||||
- Export reports
|
||||
|
||||
## Why I Built This
|
||||
|
||||
My employer uses TimeNet for attendance tracking. Opening a browser, navigating to the site, logging in, and clicking buttons for a simple clock-in felt like unnecessary friction.
|
||||
|
||||
I wanted a faster way: `timenet in` in the morning, `timenet out` when leaving. That's it.
|
||||
|
||||
## Stack
|
||||
|
||||
- **Python** for CLI logic
|
||||
- **Click** for command-line interface
|
||||
- **Requests** for API interaction
|
||||
- **Credential management** for secure token storage
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# Clock in
|
||||
timenet in
|
||||
|
||||
# Clock out
|
||||
timenet out
|
||||
|
||||
# Check status
|
||||
timenet status
|
||||
|
||||
# View today's hours
|
||||
timenet today
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
Active. I use it daily for work attendance tracking.
|
||||
Reference in New Issue
Block a user