Saltar al contenido principal

Setup del repo wildcat/wiedii-dev-onboarding

🎯 Alcance: este es el repo sandbox de práctica del onboarding (wiedii-dev-onboarding), para que un dev nuevo ensaye el flujo Git Flow sin riesgo. No es una guía de creación de proyectos: para crear un proyecto real desde cero (y qué tener en cuenta), ver repo-setup.

Checklist para el TL. Este repo debe existir antes de que llegue el primer desarrollador nuevo.

Crear el repo en GitLab​

  1. https://gitlab.wiedii.co → Grupo wildcat → New project → Create blank project
  2. Nombre: wiedii-dev-onboarding
  3. Visibilidad: Private
  4. Inicializar con README: ✅

Checklist de archivos mínimos​

El checklist completo de archivos estándar de cualquier repo (y qué tener en cuenta) está en repo-setup. Aquí solo se listan para el sandbox; lo realmente específico de este repo es CONTRIBUTORS.md (donde el dev añade su nombre) y un README.md que explique que es un repo de práctica.

  • mise.toml — herramientas del equipo (incluye wietoo para asistir/validar commits)
  • lefthook.yaml — hooks de Git (consume wiedii-configs → activa commit-msg con wietoo check-commit-msg)
  • .gitignore — estándar Wiedii
  • .gitattributes — line endings cross-platform
  • .editorconfig — formateo consistente
  • .gitlab/merge_request_templates/default.md — plantilla de MR
  • CONTRIBUTORS.md — el archivo donde el nuevo dev añade su nombre
  • CLAUDE.md — instrucciones para agentes IA
  • README.md — explicar que es un sandbox de práctica

CONTRIBUTORS.md inicial​

# Contributors

Lista de personas que han completado el onboarding de Wiedii.

## Equipo actual

- Innovation Development (@innovadev) — 2026-05-21

mise.toml mínimo​

[env]
  GOPRIVATE = "gitlab.wiedii.co/*"

[tools]
bun = "1.3.14"
"aqua:evilmartians/lefthook" = "2.1.9"
"go:gitlab.wiedii.co/wiedii-registry/wietoo-cli/cmd/wietoo" = "vX.Y.Z"  # commits — ver [[wietoo-cli#Qué versión usar]]

[hooks]
postinstall = "[ -z \"$CI\" ] && lefthook install || true"

[tasks.setup]
# ⚠️ Una sola cadena con && (NO array): el hook `toml` con reorder_arrays=true reordenaría
# los pasos al commitear y rompería el orden de ejecución.
run = "mise install --yes && mise lock && pkg=$(find . -maxdepth 2 -name 'package.json' ! -path '*/node_modules/*' | head -1) && { [ -n \"$pkg\" ] && bun install --cwd \"$(dirname \"$pkg\")\" || true; }"
description = "Configura el entorno completo del proyecto"

Configuración de GitLab​

  • Branch protection en main y develop (require MR + 1 approval + CI verde)
  • Settings → Merge requests → merge commits only, squash disabled
  • Pipeline CI con lint básico
  • Acceso del nuevo dev (¡requisito para que pueda hacer el MR!): agregarlo como miembro del proyecto con rol Developer (Manage → Members → Invite member), o compartir el proyecto con su grupo en rol Developer (Settings → Members → Invite a group). Hacerlo antes de entregarle la guía.

Por qué (caso real visto en onboarding): en GitLab, con solo lectura / rol Reporter un colaborador puede clonar y hacer pull, pero no puede crear un Merge Request — abrir un MR exige push de una rama, y eso requiere rol mínimo Developer. El colaborador tenía cuenta y podía hacer pull, pero no abrir el MR hasta que el proyecto se compartió con su grupo de usuarios. Verificar el acceso (miembro directo o vía grupo, rol Developer) es parte del mantenimiento del sandbox.

Verificación final​

Prueba el flujo completo antes de dar la guía al nuevo dev:

mkdir -p ~/Docker
git clone git@gitlab.wiedii.co:wildcat/wiedii-dev-onboarding.git ~/Docker/wiedii-dev-onboarding-test
cd ~/Docker/wiedii-dev-onboarding-test
mise run setup
git flow init --preset=classic --defaults
git flow feature start test-tl
echo "- TL test" >> CONTRIBUTORS.md
wietoo commit
git push origin feature/test-tl
glab mr create --target-branch develop --title "docs(contributors): test TL"

Si todo funciona sin errores, el sandbox está listo.

Documentos relacionados​