Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Expose Crane run cadence as an installer choice and tuning guide

Abierto
  • ¿Algo no está bien?
#8 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
github-actions
Área
devops, documentation

Línea de trabajo

Comienza con install.md y sigue cómo se gestiona la cadence prompt; después, inspecciona workflows/crane.md y el paso gh aw compile. Compara las indicaciones sobre cadence necesarias en README.md y create-migration.md, incluida la diferencia entre workflow cadence y migration schedule frontmatter. La tarea está terminada cuando la cadence seleccionada se aplica antes de la compilación, las ventajas y desventajas están documentadas y las pruebas pertinentes de documentación o de prompts pasan correctamente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

documentation enhancement

Background

The githubnext/apm migration needed faster iteration than the default Crane cadence. APM locally changed the Crane workflow schedule from every 6h to every 20m so Crane could converge in hours rather than days while maintainers were actively watching.

That should not necessarily become the upstream default. It should become an explicit installation and tuning choice.

Problem

The upstream Crane workflow defaults to a fixed schedule. The README explains that users can tune cadence, and install.md asks about migration frequency, but the installed workflow still needs a clear path for applying and documenting the chosen cadence.

Different migrations need different cadences:

  • Active, high-attention migration: every 20m or every 1h.
  • Normal migration in a busy repository: every 6h.
  • Low-risk background migration: daily or weekly.
  • Multiple active migrations: cadence interacts with the scheduler because each run selects only one migration.

If the cadence is too slow, Crane appears idle and migrations take too long. If it is too fast, maintainers get too many commits and CI runs.

Proposed implementation

Update Crane installation and documentation so cadence is a first-class choice.

Implementation options:

  1. In install.md, keep the frequency prompt but make the follow-through explicit:

    • The agent should edit workflows/crane.md to set on.schedule to the selected cadence.
    • Then it should run gh aw compile crane.

  2. In README.md, add a cadence tuning section with examples:

on:
  schedule: every 20m

on:
  schedule: every 1h

on:
  schedule: every 6h

  1. Explain trade-offs:

    • Faster cadence gets feedback quickly but increases CI usage and review pressure.
    • Slower cadence is calmer but may make migrations look stalled.
    • For multiple migrations, faster workflow cadence may still run only one selected migration per trigger.

  2. Consider adding guidance to create-migration.md for per-migration schedule: frontmatter versus workflow-level cadence. Users should understand both knobs:

    • Workflow cadence: how often Crane wakes up.
    • Migration schedule: whether a specific migration is due when Crane wakes up.

Suggested test coverage

  • Documentation test or prompt test that asserts install.md says to update workflows/crane.md and compile after selecting cadence.
  • If installer automation exists, test that the selected cadence changes the workflow source before compilation.

Acceptance criteria

  • A new Crane installer run asks for cadence and applies it to the workflow source.
  • Documentation explains recommended cadence ranges and trade-offs.
  • Documentation distinguishes workflow wake-up cadence from per-migration schedule frontmatter.
  • Users can reproduce the APM-style fast loop intentionally without hand-editing undocumented workflow internals.

Provenance

This came from githubnext/apm, where changing Crane to every 20m helped the Python-to-Go migration converge much faster while humans were actively reviewing.

Lenguaje dominante
Python
Estrellas
10
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de githubnext/crane

Todos los issues de githubnext/crane

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.