Introducción
Cedar & Common está organizando una jornada vecinal. Su programa oficial ya está disponible y dos propuestas necesitan vistas previas separadas. Jenkins puede generar ambas ramas, pero sus Pipelines actuales publican en el mismo lugar. Una ejecución correcta por sí sola no mantendrá disponibles ambas ideas.
Descubrirás las ramas, observarás esa colisión, cambiarás sus Jenkinsfiles y publicarás dos vistas previas utilizables. Después cambiarás una hora de encuentro y confirmarás que su vista previa se actualiza mientras la otra propuesta permanece intacta.
Los requisitos previos son conocimientos básicos de introducción de comandos en el terminal y rutas, navegación por las páginas de Jenkins y reconocimiento de un Pipeline declarativo breve. Las ramas de Git, los commits, el envío de cambios, la indexación y los nuevos ajustes del Pipeline se explican antes de utilizarlos. El repositorio, el generador Java, el publicador y los complementos de Jenkins están preparados; no los instalarás ni escribirás el sitio web. Se trata de un origen y un servicio de vistas previas locales de prácticas en una única máquina virtual, no de GitHub ni de una plataforma de despliegue de producción. La duración es una estimación del autor, no un tiempo medido con principiantes.
Descubre las propuestas y las ejecuciones de sus ramas
En este paso inspeccionarás los programas normales y el código de las propuestas, después descubrirás sus trabajos de rama y observarás la colisión en la vista previa compartida. Empieza en Preview Desk.
Selecciona Open the official program. Confirma Common Ground Day y 09:30. Selecciona Explore this plan y comprueba las tres actividades y la ilustración de la ruta. Selecciona Download the activities para obtener un CSV real y Read visitor notes para el texto completo. Usa la acción Back del navegador para volver al resumen y luego Back de nuevo para volver al escritorio. Abre también Read the courtyard notes y confirma Courtyard Stories. Ambos programas existentes deben permanecer disponibles durante todo tu trabajo.
Cambia a Source. Este terminal es una copia de trabajo de Git: los archivos que puedes editar pertenecen a una sola rama seleccionada a la vez. Una rama es una línea de historial de código con nombre. Cambiar de rama cambia los archivos de trabajo a la versión de esa rama; no cambia la otra rama. Un commit es una versión registrada del contenido del repositorio, identificada mediante un hash; ese identificador vinculará una ejecución de Jenkins con su código de origen.
El terminal se abre en /home/labex/project/community-site. pwd muestra el directorio actual. git --no-pager branch --list enumera las ramas locales, con * para señalar la seleccionada. --no-pager mantiene el resultado directamente en el terminal. Sin esa opción, Git puede abrir un visor interactivo; si ves (END) en lugar del indicador del shell, pulsa q para salir del visor. Ejecuta:
pwd
git --no-pager branch --list
La lista incluye main, courtyard-notes, garden-plan y river-plan. La selección preparada es garden-plan. Si cambias de directorio accidentalmente, vuelve con cd /home/labex/project/community-site antes de continuar.
cat muestra un archivo sin modificarlo. event.properties almacena un ajuste key=value por línea para el título, los detalles del encuentro y las actividades. Lee este pequeño archivo de datos:
cat event.properties
Describe Garden Gathering, con un encuentro a las 10:00 junto a Glasshouse gate. La línea meeting_time es un dato utilizado por el generador proporcionado, que produce conjuntamente las páginas, el CSV y las notas.
git switch selecciona una rama en esta copia de trabajo. Compara la segunda propuesta y después vuelve:
git switch river-plan
cat event.properties
git switch garden-plan
La segunda propuesta es Riverside Picnic, con un encuentro a las 14:00 junto a River steps. Son archivos de código realmente diferentes, no una sola página con una etiqueta de rama distinta.
Tu alcance de edición comprende el Jenkinsfile de las ramas candidatas y el cambio posterior solicitado de meeting_time en event.properties. Mantén sin cambios las plantillas, la imagen de la ruta, el generador y el publicador. No edites, elimines, cambies de nombre ni vuelvas a crear el proyecto de Jenkins preparado ni los trabajos de rama. Conserva todo el historial de Git y Jenkins y todos los archivos comprimidos conservados de las vistas previas, las ramas main y courtyard-notes, el programa oficial y la vista previa del patio. Este ejercicio no requiere Docker ni comandos de administrador.
En este punto, identifica qué propuesta empieza a las 10:00 y cuál a las 14:00. Todavía no se ha publicado ninguna vista previa de las propuestas.
Ahora ejecuta el descubrimiento nativo de ramas de Jenkins y compara las ejecuciones correctas con su resultado real de publicación. Cambia a Jenkins y abre community-previews desde Dashboard.
Este proyecto padre preparado es un Multibranch Pipeline. Explora un repositorio Git en busca de ramas que contengan un Jenkinsfile y crea un trabajo Pipeline hijo para cada una. El origen utiliza un pequeño servicio Git de solo lectura dentro de este entorno de prácticas; el origin preparado de la copia de trabajo es donde tus envíos posteriores publicarán los cambios de código. No se necesitan cuentas externas ni credenciales.
Espera a que termine de cargarse la página de Jenkins y selecciona Scan Multibranch Pipeline Now. Abre Scan Multibranch Pipeline Log y espera a Finished: SUCCESS. La exploración descubre garden-plan y river-plan; main y courtyard-notes no contienen ningún Jenkinsfile y no son trabajos candidatos. Vuelve mediante el enlace community-previews de la ruta de navegación. Espera a que terminen ambas ejecuciones hijas.
Abre garden-plan, después su ejecución numerada y Console Output. Su salida debe identificar Garden Gathering, 10:00 y la revisión de código extraída. Vuelve mediante community-previews, abre river-plan e inspecciona la consola de su ejecución numerada. Debe identificar Riverside Picnic, 14:00 y su propia revisión de código. Ambas deben terminar en SUCCESS. En este entorno preparado puede aparecer un mensaje de herramienta Git Using Default antes de una extracción correcta; lee la revisión real y el resultado final para determinar si se completó la extracción.
Cambia a Source. Lee el Pipeline proporcionado:
cat Jenkinsfile
options { skipDefaultCheckout() } desactiva la extracción implícita del código del Pipeline declarativo para que la etapa visible Check out this branch la realice explícitamente. checkout scm utiliza la revisión concreta de la rama que proporcionó este Jenkinsfile. No la sustituyas por una extracción de una rama fija.
La etapa proporcionada Build preview transforma ese código extraído en archivos reales para visitantes. Archive preview conserva preview.zip en Jenkins antes de que Publish preview envíe esos mismos bytes al escritorio local. El bloque final post utiliza deleteDir() para vaciar el espacio de trabajo de esa ejecución. Conserva estas etapas y la limpieza.
Un bloque environment proporciona valores a las etapas. Ambas ramas contienen actualmente este mismo ajuste:
PREVIEW_KEY = 'shared'
PREVIEW_KEY elige la dirección de publicación del escritorio. La cadena literal 'shared' envía ambas ejecuciones a una sola ubicación, aunque sus extracciones de código sean diferentes. Vuelve a Preview Desk y actualiza la página. Hay una tarjeta de propuesta shared, que muestra la rama que se haya publicado en último lugar. Selecciona su enlace Open preview y compara su título con las dos ejecuciones de origen correctas. No puedes compartir dos vistas previas independientes desde esa única dirección.
Usa la acción Back del navegador para volver al escritorio. El programa oficial y las notas del patio deben seguir funcionando. Ahora has observado por qué los trabajos de rama separados no implican automáticamente resultados publicados separados.
Asigna a cada rama su propia vista previa
En este paso cambiarás y publicarás el Jenkinsfile de cada rama y después generarás ambas vistas previas independientes. Empieza en Source, en /home/labex/project/community-site.
Jenkins proporciona env.BRANCH_NAME en una ejecución multirrama. Es el nombre de la rama actual, como garden-plan. Sustituye el valor compartido por esa identidad nativa de la rama:
PREVIEW_KEY = "${env.BRANCH_NAME}"
Las comillas dobles de Groovy permiten que ${...} inserte el valor de la variable. Las comillas simples alrededor de esta expresión conservarían sus caracteres literales. Los nombres de rama de este ejercicio ya utilizan letras minúsculas simples y guiones adecuados para direcciones de vistas previas; esto no es una regla general de saneamiento para nombres de rama arbitrarios.
Selecciona primero la propuesta del jardín. git status --short muestra los cambios sin confirmar de forma compacta; M significa un archivo modificado y la ausencia de salida significa que la copia de trabajo está limpia. nano es un editor de terminal para el archivo indicado; mantiene el control de este terminal hasta que guardes y salgas.
git switch garden-plan
git status --short
nano Jenkinsfile
nano edita el archivo indicado en este terminal. Usa las teclas de flecha para llegar a la línea PREVIEW_KEY. Pulsa Home para ir a su principio y después Ctrl+K una vez para cortar esa única línea. Escribe la línea de sustitución completa mostrada arriba, incluida su sangría, y pulsa Enter para mantener separada la siguiente línea RECEIVER_URL. No cortes más líneas. Guarda con Ctrl+O, pulsa Enter para confirmar Jenkinsfile y sal con Ctrl+X. Aquí Ctrl significa mantener pulsada la tecla Control, también en macOS.
Inspecciona tu edición antes de guardarla en el historial de Git. git diff compara el archivo de trabajo con su versión confirmada. Como antes, --no-pager muestra el resultado directamente en el terminal; -- separa las opciones de la ruta del archivo. Ejecuta:
git --no-pager diff -- Jenkinsfile
El diff debe mostrar únicamente la eliminación de la antigua línea PREVIEW_KEY y la adición de la nueva. Los prefijos - y + describen texto eliminado y añadido; no son caracteres que debas escribir en el archivo. Si el diff incluye un cambio involuntario, vuelve a abrir nano Jenkinsfile, corrígelo, guarda, sal e inspecciona de nuevo. Si ves un error de archivo no encontrado, ejecuta pwd y vuelve al directorio de trabajo indicado arriba.
Un commit registra el cambio de código preparado en la rama seleccionada. git add prepara este archivo; git commit -m lo registra con el mensaje proporcionado; git push origin garden-plan publica esa rama en el repositorio de origen preparado para que Jenkins pueda descubrir el nuevo commit. En estos comandos de commit, las comillas dobles mantienen unido el mensaje de varias palabras como un solo argumento. Estos comandos cambian el historial del código, no directamente la vista previa en funcionamiento:
git add Jenkinsfile
git commit -m "Give the garden plan its own preview"
git push origin garden-plan
Ahora aplica el mismo ajuste a la otra propuesta:
git switch river-plan
git status --short
nano Jenkinsfile
Sustituye únicamente su línea PREVIEW_KEY mediante la misma operación de nano y la expresión exacta entre comillas dobles. Guarda y sal. Inspecciona, confirma y envía esta rama:
git --no-pager diff -- Jenkinsfile
git add Jenkinsfile
git commit -m "Give the river plan its own preview"
git push origin river-plan
Si Git se niega a cambiar de rama porque hay cambios sin confirmar, ejecuta git status --short e inspecciona primero el diff de la rama actual. Termina o corrige esa edición prevista antes de cambiar de rama; no descartes archivos ni restablezcas el repositorio. Si git commit indica que no hay nada que confirmar después de que ya hayas confirmado la edición prevista, inspecciona git --no-pager log -1 --oneline y continúa con el envío de la rama. -1 limita esta vista a un commit; --oneline muestra su identificador abreviado y su mensaje.
Cambia a Jenkins, vuelve a community-previews mediante la ruta de navegación y selecciona Scan Multibranch Pipeline Now de nuevo. No hay ningún webhook en este ejercicio local, por lo que enviar el código por sí solo no solicita una exploración. Espera a que la exploración y ambas nuevas ejecuciones hijas terminen correctamente. Cada consola debe mostrar la clave de vista previa de su propia rama. Si una ejecución informa de un error de sintaxis de Groovy, corrige las comillas y llaves de su Jenkinsfile en Source, confirma y envía la corrección en esa rama y vuelve a explorar. No edites un trabajo hijo generado en lugar de su código de origen.
Cambia a Preview Desk y actualiza la página. Ahora debe haber tarjetas separadas garden-plan y river-plan. La antigua tarjeta compartida puede permanecer como el resultado anterior observado. Abre el enlace Open preview de cada propuesta y comprueba su título correcto, hora de encuentro, tres actividades, imagen de la ruta, CSV y notas para visitantes. Después de explorar una propuesta, usa la acción Back del navegador para volver a su resumen y después Back de nuevo para volver al escritorio antes de abrir la otra tarjeta. Las dos direcciones de vista previa deben ser diferentes y seguir siendo utilizables al mismo tiempo.
Busca las claves garden-plan y river-plan sobre sus propios títulos y horas de encuentro originales. La tarjeta shared conservada muestra la colisión anterior; no sustituye a ninguna de las vistas previas independientes.
En Jenkins, abre la página de estado de la última ejecución correcta de cada rama y descarga preview.zip desde Build Artifacts. Extrae cada ZIP en una carpeta nueva diferente y abre index.html. Mantén los siete archivos juntos. Las páginas y los adjuntos deben funcionar localmente; un adjunto de texto puede abrirse directamente en lugar de iniciar otra descarga. build.json identifica la rama y el commit reales de origen. Estas vistas previas completas son el resultado; dos etiquetas verdes de ejecución por sí solas no son suficientes.
Actualiza una propuesta y conserva la otra
En este paso cambiarás la hora de encuentro del jardín y utilizarás otra exploración para actualizar solo la vista previa de esa rama. Empieza en Jenkins y anota el número de la última ejecución correcta de river-plan. Mantén abierta su vista previa para compararla.
Cambia a Source. Selecciona la rama del jardín y edita su pequeño archivo de datos:
git switch garden-plan
git status --short
nano event.properties
Cambia únicamente la línea completa meeting_time de meeting_time=10:00 a:
meeting_time=10:30
Utiliza las mismas teclas de flecha, Home, una pulsación de Ctrl+K, el texto de sustitución y Enter que utilizaste para la línea del Pipeline. Guarda con Ctrl+O, Enter y sal con Ctrl+X. El generador lee este único valor para mantener coherentes la página, el CSV y las notas; no editas los archivos generados para visitantes.
Revisa y publica esta actualización del código:
git --no-pager diff -- event.properties
git add event.properties
git commit -m "Move the garden meeting to 10:30"
git push origin garden-plan
El diff debe cambiar únicamente esa hora de encuentro. Si no es así, corrige el archivo antes de confirmar. La rama del río no recibe ningún cambio de código.
Cambia a Jenkins, vuelve a community-previews y selecciona Scan Multibranch Pipeline Now. Después de la indexación, el trabajo del jardín debe realizar una nueva ejecución para su revisión modificada; la rama del río, sin cambios, debe conservar el número de ejecución que anotaste. Espera a que la ejecución del jardín termine en SUCCESS. Abre su Console Output y relaciona el nuevo commit y 10:30 con el cambio de código.
Si la exploración indica que no hay cambios y la vista previa del jardín sigue siendo la antigua, vuelve a Source. Comprueba git status --short y git --no-pager log -1 --oneline, confirma que el cambio previsto se haya registrado en un commit en garden-plan y envía esa rama antes de volver a explorar. Una edición o un commit local que no haya llegado a origin aún no es código que Jenkins pueda descubrir. Si una ejecución falla, lee su consola y corrige el error de código indicado mediante otro commit y envío. No restablezcas la máquina virtual ni sustituyas el generador proporcionado.
Cambia a Preview Desk y actualiza la página. Abre garden-plan: Garden Gathering ahora debe reunirse a las 10:30. Inspecciona Explore this plan, el CSV de actividades descargado y las notas completas para visitantes; la hora de encuentro debe coincidir en todas partes. Abre river-plan: Riverside Picnic debe seguir reuniéndose a las 14:00, con sus actividades originales y adjuntos funcionales. Su build.json debe conservar el commit de origen y el número nativo de ejecución anteriores. No vuelvas a ejecutar ese trabajo hijo sin cambios durante esta actualización final.
Vuelve a Jenkins y descarga el preview.zip más reciente del jardín. Extráelo en otra carpeta nueva y repite las comprobaciones locales de página, imagen, CSV y notas. Debe identificar el nuevo commit del jardín; el paquete del río descargado anteriormente debe seguir siendo utilizable de forma independiente.
Por último, vuelve a Preview Desk, abre Open the official program y Read the courtyard notes, y confirma que ambos programas completos permanecen intactos. Conserva los historiales originales de ramas y ejecuciones. Si haces cualquier otra edición del código, confirma, envía y completa la ejecución de Jenkins correspondiente antes de comprobar que has terminado. Tienes dos vistas previas en funcionamiento y evidencia de que actualizar una no sobrescribió ni volvió a generar la otra.
Resumen
Has utilizado el descubrimiento nativo de Multibranch y la revisión de código que hay detrás de cada Jenkinsfile, y después has separado la publicación mediante la identidad de rama de Jenkins. Ambas propuestas tienen ahora páginas, imágenes y adjuntos utilizables en direcciones independientes. Un commit posterior del jardín actualizó únicamente su propia vista previa, mientras la ejecución del río, el programa oficial y la vista previa del patio permanecieron intactos.
