Dockerfile, un README y un icono. El catálogo se construye a partir de ese repositorio, así que no hay formulario de envío en el panel. Este tutorial lleva el bot del primer tutorial desde “funciona como plantilla privada” hasta una pull request abierta, y el mismo camino sirve para plantillas de imagen.
Las plantillas del catálogo muestran una insignia Comunidad y tu nombre, son siempre de código abierto y los empaqueta el build de Vertra a partir del commit que se fusionó, así que nadie depende de tu cuenta para que sigan disponibles.
Antes de empezar
La CLI de Vertra y una cuenta de GitHub.
Código que tengas permiso para distribuir públicamente, con una licencia compatible. Los revisores lo comprueban.
code.view: false, env_hidden y share.full_copy se rechazan en las plantillas públicas con forbidden_in_public. Si tu plantilla es una plantilla cerrada, se queda como privada.
Paso a paso
1
Pruébalo primero como plantilla privada
Una plantilla privada y una pública se ejecutan sobre el mismo motor, así que la prueba más barata es usar tu plantilla de verdad. Partiendo de un estado limpio, comprueba al menos:
- Despliegue nuevo desde el asistente o con
vertra template deploy, respondiendo a las preguntas con valores realistas, y luego la primera pantalla del software. - Los valores predeterminados. Despliega otra vez aceptando todos los valores predeterminados: debe arrancar sin pasos adicionales.
- Los caminos omitidos. Si un
wheno una opción desactiva servicios, despliega cada variante. - Reinicio y actualización. Reinicia la aplicación, publica la versión
1.0.1y actualiza una aplicación, y luego haz rollback. Los datos deben sobrevivir a los reinicios. - RAM mínima. Despliega con el valor de
ram.miny vigila el log por si hay procesos terminados por falta de memoria.
2
Comprueba que la plantilla es elegible
La revisión busca esto, así que míralo antes:
- Sin mineros, telemetría oculta, llamadas a servidores ajenos ni secretos en el código.
- Una licencia que permita la distribución pública, enlazada en
links.license. - Código abierto: la plantilla debe ser totalmente visible, sin
env_hidden. - Una versión fija del software, con su imagen fijada (consulta el paso del manifiesto).
- Un README que otra persona pueda seguir sin preguntarte nada.
secret para las claves); un secreto literal en el manifiesto se rechaza con secret_in_manifest.3
Prepara la carpeta
Haz un fork del repositorio del catálogo, clona tu fork y crea una carpeta con el nombre del Una plantilla de código trae su código (
id de la plantilla, como hacen las plantillas existentes:src/); una plantilla de imagen trae su Dockerfile y todo lo que necesita el build, sin src/. La carpeta docs/ contiene páginas más largas que alimentan la página de la plantilla en el sitio de documentación; el panel muestra solo el README.4
Adapta el manifiesto a las reglas del catálogo
Copia el manifiesto de tu plantilla privada y cambia lo que difiere:
Para el bot, el manifiesto del catálogo queda así:
vertracloud.template.yaml (catalog)
Para una plantilla de imagen, el manifiesto del catálogo lleva
source: { type: image, image: "docker.io/vendor/app@sha256:<64 hex digits>", context: . }. La imagen se fija por digest para que cada despliegue ejecute exactamente los mismos bytes, y el Dockerfile de la carpeta lo compila el pipeline del catálogo en una imagen que pertenece a la plataforma, no a ti.5
Añade el icono
icon.svg es un archivo vectorial simple, por ejemplo de 128 por 128. El catálogo rechaza un SVG que contenga scripts, foreignObject, atributos de evento como onload= o referencias a recursos externos:icon.svg
6
Escribe el README
El README es la página de la plantilla. Las plantillas existentes del catálogo lo escriben en tres secciones (portugués, inglés y español) con la misma estructura. Cubre lo que la plantilla ofrece al usuario y lo que conviene saber:Di cosas ciertas: la memoria que necesita la plantilla, qué se crea, qué debe hacer el usuario tras el despliegue, qué no hace la plantilla y la licencia del software empaquetado.
README.md
7
Valida antes de hacer push
source.path, sin código cerrado), así que relee la tabla del paso del manifiesto antes del push. Consulta Validar y probar para saber cómo leer cada hallazgo.8
Abre la pull request
Haz commit de la carpeta en una rama de tu fork y abre una pull request al repositorio del catálogo. En cada pull request el pipeline:
- Valida el manifiesto con el esquema y las reglas (placeholders,
when, permisos, slugs de plan). - Compila la imagen, cuando la plantilla tiene un
Dockerfile, o resuelve la imagen fijada. - Busca file capabilities en la imagen: un binario con una de ellas no se ejecuta con las restricciones de la plataforma.
- Comprueba la licencia declarada.
9
Pasa la revisión
Una persona de Vertra ejecuta la plantilla en la plataforma con la memoria mínima que declaraste y revisa la seguridad (sin mineros, sin telemetría oculta, sin secretos en el código), la licencia y la calidad del README. Espera comentarios y respóndelos en la pull request. Cuando se aprueba y se fusiona, el pipeline empaqueta la carpeta en ese commit como una versión de la plantilla y la publica con la insignia Comunidad y tu nombre. Las versiones posteriores son nuevas pull requests, revisadas del mismo modo. Una plantilla de la comunidad que deja de mantenerse puede marcarse como obsoleto: sale de la galería, las aplicaciones ya creadas siguen funcionando y reciben un aviso.
El camino hasta el catálogo público es la pull request, hecha a mano: no hay ningún botón en el panel. Una plantilla cerrada nunca va al catálogo.
Solución de problemas
Próximos pasos
- Contribuir al catálogo público: la lista de comprobación y los criterios de revisión en una sola página.
- Validar y probar: probar como privado y leer los hallazgos de validación.
- Referencia del manifiesto: los campos que exige el catálogo.
- Esquema del manifiesto: el JSON Schema que usan los editores y la CI.
- Referencia de errores: códigos de error de validación y despliegue.
- Plantillas privadas: versiones, workspaces y el límite de 5.