Adoptar jobs del dashboard en IaC
Use steadycron export para trasladar sus jobs existentes del dashboard a un manifiesto YAML y empiece a gestionar su cuenta como código.
Si ya tiene jobs en el dashboard de SteadyCron, steadycron export exporta el estado
completo de su cuenta a un manifiesto YAML. A partir de ese momento puede commitearlo
en git, revisar los cambios en PRs y aplicarlos con la CLI — sin perder ningún job
existente.
Paso 1 — crear una clave de API
Vaya a Configuración → Claves de API en el dashboard y cree una clave. Asígnele el scope de escritura para que la CLI pueda leer y aplicar.
Copie la clave — solo la verá una vez.
Paso 2 — exportar su cuenta
export STEADYCRON_API_KEY=sc_...
steadycron export --namespace my-app > manifests/my-app.yaml
El flag --namespace asigna todos los recursos exportados a este namespace. A partir
de ahora, apply --prune solo eliminará recursos dentro de my-app — no los jobs
que cree después desde el dashboard (esos van al namespace por defecto).
Si gestiona múltiples entornos, exporte cada uno por separado con un namespace diferente:
steadycron export --namespace production > manifests/production.yaml
steadycron export --namespace staging > manifests/staging.yaml
Paso 3 — revisar el manifiesto exportado
Abra el archivo. Verá:
- Cada job con su calendario, tipo y configuración
- Un campo
iden cada recurso (asignado automáticamente si no estaba presente) - Los secrets reemplazados por marcadores de posición
${VAR_NAME}— seguro para committear tal cual - Las variables de plantilla conservadas como
{{var}}— también seguras para committear
Añada valores id a cualquier recurso que no tenga uno. Los IDs son el mecanismo
con el que la CLI rastrea la identidad estable. Una vez que haga commit, cambiar un ID
se trata como una eliminación más una creación.
Paso 4 — validar
steadycron validate manifests/my-app.yaml
Corrija los errores reportados antes de continuar.
Paso 5 — hacer commit
git add manifests/
git commit -m "chore: adopt SteadyCron account into IaC"
Su manifiesto es ahora la única fuente de verdad. Los cambios futuros deben realizarse a través de este archivo, no mediante click-ops en el dashboard.
Paso 6 — configurar CI
Conecte GitHub Actions para publicar un diff del plan en cada PR y aplicar al hacer merge:
- Configuración CI/CD — flujos de trabajo de GitHub Actions listos para copiar
Realizar cambios tras la adopción
El flujo de trabajo a partir de ahora:
- Editar
manifests/my-app.yaml - Hacer push de una rama y abrir un PR
- CI publica el diff del plan como comentario
- Merge → CI aplica el cambio
Añadir un nuevo job desde el dashboard después de la adopción: está bien. Los jobs
creados desde el dashboard van al namespace por defecto y no serán afectados por un
apply --prune con namespace. Si más adelante quiere incorporar esos jobs a IaC,
vuelva a ejecutar export para ese namespace y combine la salida con su manifiesto.
Acerca de --prune
Una vez que gestione un namespace con la CLI, use apply --prune en CI. Esto garantiza
que los jobs eliminados del manifiesto también se eliminen de su cuenta — manteniendo
el manifiesto como el único registro autorizado.
Sin --prune, sync creará y actualizará pero nunca eliminará. Los jobs removidos del
manifiesto permanecerán en su cuenta a menos que los elimine manualmente.
Temas relacionados
- Flujo de trabajo IaC — referencia completa de comandos CLI
- Referencia del manifiesto — cada campo documentado
- Migrar desde crontab — convertir un archivo crontab