CONFIG: estandarizar estructura de github (acciones, plantillas y dependabot)
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: Reporte de Error (Bug)
|
||||
about: Crea un reporte para ayudarnos a mejorar el sistema
|
||||
title: '[BUG] '
|
||||
labels: bug
|
||||
assignees: ''
|
||||
---
|
||||
|
||||
## Describe el error
|
||||
Una descripción clara y concisa de lo que está fallando.
|
||||
|
||||
## Pasos para reproducirlo
|
||||
1. Ir a '...'
|
||||
2. Hacer clic en '....'
|
||||
3. Navegar hasta '....'
|
||||
4. Ver el error
|
||||
|
||||
## Comportamiento esperado
|
||||
Una descripción clara de lo que se esperaba que sucediera.
|
||||
|
||||
## Capturas de pantalla
|
||||
Si aplica, añade capturas de pantalla para ayudar a explicar tu problema.
|
||||
|
||||
## Entorno (por favor completa esta información):
|
||||
- SO: [ej. Windows, Mac]
|
||||
- Navegador [ej. chrome, safari]
|
||||
- Versión [ej. 22]
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: Solicitud de Funcionalidad
|
||||
about: Sugiere una idea para este proyecto
|
||||
title: '[NUEVO] '
|
||||
labels: enhancement
|
||||
assignees: ''
|
||||
---
|
||||
|
||||
## ¿Tu solicitud está relacionada con un problema?
|
||||
Explica clara y concisamente cuál es el problema. Ej. Siempre me frustra cuando [...]
|
||||
|
||||
## Describe la solución que te gustaría
|
||||
Una descripción clara de lo que quieres que suceda.
|
||||
|
||||
## Describe alternativas que hayas considerado
|
||||
Una descripción clara de cualquier solución alternativa que hayas pensado.
|
||||
|
||||
## Contexto adicional
|
||||
Añade cualquier otro contexto o capturas de pantalla sobre la solicitud aquí.
|
||||
@@ -0,0 +1,24 @@
|
||||
## Descripción del PR
|
||||
<!-- Describe aquí el propósito de tus cambios. ¿Qué problema resuelve o qué nueva característica añade? -->
|
||||
|
||||
|
||||
## Cambios Realizados
|
||||
<!-- Enumera los cambios técnicos más importantes. -->
|
||||
- [ ] Cambio A
|
||||
- [ ] Cambio B
|
||||
|
||||
## Tipo de Cambio
|
||||
<!-- Marca la casilla correspondiente con una 'x' -->
|
||||
- [ ] NUEVO: Funcionalidad nueva
|
||||
- [ ] CORRECCIÓN: Resolución de un error
|
||||
- [ ] MEJORA: Refactorización técnica o de rendimiento
|
||||
- [ ] CONFIG: Cambios en Docker, dependencias, o CI/CD
|
||||
- [ ] DOCS: Actualización de documentación
|
||||
|
||||
## ¿Cómo se probó esto?
|
||||
<!-- Explica brevemente los pasos para probar tus cambios localmente. -->
|
||||
|
||||
## Checklist (Para el revisor)
|
||||
- [ ] El código sigue los estándares del proyecto.
|
||||
- [ ] No hay credenciales (secrets) expuestas en los archivos.
|
||||
- [ ] Se probó en entorno local/Docker.
|
||||
@@ -0,0 +1,10 @@
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
@@ -0,0 +1,33 @@
|
||||
name: CI/CD Pipeline
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ "main" ]
|
||||
pull_request:
|
||||
branches: [ "main" ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Python 3.11
|
||||
uses: actions/setup-python@v5
|
||||
with:
|
||||
python-version: "3.11"
|
||||
cache: 'pip'
|
||||
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
|
||||
- name: Django Syntax Check
|
||||
env:
|
||||
SECRET_KEY: 'test-key-for-ci'
|
||||
DEBUG: 'True'
|
||||
DATABASE_URL: 'sqlite:///:memory:'
|
||||
run: |
|
||||
python manage.py check
|
||||
@@ -206,20 +206,18 @@ Este proyecto utiliza **GitHub Flow** y **Conventional Commits** para mantener u
|
||||
- Para cada nueva funcionalidad o corrección, se crea una rama nueva a partir de `main` (ej: `feature/agregar-modulo-nomina`).
|
||||
- Una vez terminado el desarrollo en la rama, se realiza un Pull Request hacia `main`.
|
||||
|
||||
### 2. Formato de Commits (Conventional Commits)
|
||||
Los mensajes de commit deben seguir esta estructura:
|
||||
`<tipo>(<alcance opcional>): <descripción breve>`
|
||||
### 2. Formato de Commits
|
||||
Los mensajes de commit deben estar en español, ser descriptivos y concentrarse en los cambios verdaderamente importantes. Seguiremos esta convención adaptada:
|
||||
`[Tipo] (<alcance opcional>): <Descripción clara del cambio>`
|
||||
|
||||
**Tipos permitidos:**
|
||||
- `feat:` Una nueva funcionalidad.
|
||||
- `fix:` Corrección de un error (bug).
|
||||
- `refactor:` Cambios en el código que no corrigen errores ni añaden funcionalidades (ej. aplicar POO).
|
||||
- `docs:` Cambios en la documentación.
|
||||
- `chore:` Tareas de mantenimiento, actualización de dependencias.
|
||||
- `style:` Cambios de formato (espacios, comas, etc) que no afectan la lógica.
|
||||
- `test:` Agregar o modificar pruebas.
|
||||
- `NUEVO:` Añade una funcionalidad importante o un nuevo módulo.
|
||||
- `CORRECCIÓN:` Soluciona un error (bug) en el sistema.
|
||||
- `MEJORA:` Refactorización o mejora técnica que no añade funcionalidades nuevas ni corrige errores, pero optimiza el código (ej. aplicar POO o hacer consultas más rápidas).
|
||||
- `CONFIG:` Cambios en configuraciones de infraestructura, Docker, dependencias o variables de entorno.
|
||||
- `DOCS:` Adiciones importantes a la documentación o manuales.
|
||||
|
||||
*Ejemplo:* `feat(gastos): agregar soporte multidivisa para proveedores`
|
||||
*Ejemplo:* `NUEVO (gastos): añade soporte multidivisa al momento de pagar a proveedores`
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user