/tags/github-actions/Recent content in GitHub Actions by Manuel ToralesWed, 15 Apr 2026 00:00:00 -0600/blog/ecobici-collector/Wed, 15 Apr 2026 00:00:00 -0600/blog/ecobici-collector/<p>He construido y publicado <strong><a href="https://github.com/jmtoral/ecobici-collector" target="_blank" rel="noopener" >EcoBici Collector</a > </strong>, un pipeline automatizado para recolectar datos de disponibilidad de bicicletas en EcoBici (CDMX) y entrenar un modelo de clasificación. El objetivo es simple: estimar la probabilidad de encontrar al menos una bicicleta funcional en una estación dada, a cualquier hora del día y día de la semana.</p> <h3 id="el-problema-con-la-programación-convencional">¿El problema con la programación convencional?</h3> <p>El proyecto inició usando los <em>cron jobs</em> de <strong>GitHub Actions</strong> como único programador (<em>scheduler</em>). Aunque funcionaba, rápidamente me topé con la realidad: las colas compartidas en GitHub provocan retrasos inconsistentes de entre 5 y 30 minutos. Para un pipeline de recolección de datos que necesita coherencia temporal (cada 15 minutos exactos), esta variabilidad destruía la integridad del dataset.</p> <h3 id="la-solución-arquitectura-de-dual-trigger">La solución: Arquitectura de &ldquo;Dual Trigger&rdquo;</h3> <p>Para garantizar precisión sin sacrificar redundancia, rediseñé la arquitectura hacia un enfoque híbrido:</p> <ul> <li><strong>Google Cloud Scheduler (Principal)</strong>: Ejecuta una solicitud HTTP POST cada 15 minutos con precisión de segundos.</li> <li><strong>Supabase (Backend)</strong>: Sirve como base de datos PostgreSQL y Edge Function para recibir la invocación y persistir los datos (snapshots).</li> <li><strong>GitHub Actions (Respaldo y Mantenimiento)</strong>: Se encarga de reentrenar semanalmente el modelo usando los datos de Supabase, generar nuevas versiones (<code>.pkl</code>) y funge como disparador de respaldo por si el Scheduler de GCP llega a fallar.</li> </ul> <h3 id="el-modelo">El Modelo</h3> <p>Recolectar millones de filas de GBFS no sirve de mucho si no se traducen en un producto analítico. Cada domingo a las 3:00 am, el cluster se despierta, extrae la historia completa y entrena un modelo que utiliza características temporales (<em>sine/cosine embeddings</em> de horas y días) y geográficas para responder la gran pregunta: <em>&ldquo;Si voy a la estación X un martes a las 8am, ¿qué tan probable es que logre llevarme una bici?&rdquo;</em></p> <p>El stack demuestra cómo diseñar sistemas escalables casi gratuitos: combinando el tier libre de GCP, Supabase y Streamlit Community Cloud para el dashboard final.</p> <p><a href="https://github.com/jmtoral/ecobici-collector" target="_blank" rel="noopener" ><strong>Puedes ver el código completo y la arquitectura en mi repositorio de GitHub.</strong></a > </p>