Introducció
Aquest document descriu els passos necessaris per migrar els repositoris de GitHub Enterprise Cloud (GHEC) al nou tenant amb data residency a Europa. Aquesta migració ve acompanyada de l’alliberament d’una nova release v5 de workflows reutilitzables, la qual suposa també canvis importants en la gestió dels artefactes i paquets generats durant els processos de CI/CD gràcies a la integració amb el nou repositori JFrog Artifactory.
Passos per a la migració
Canviar possibles referències a mòduls Terraform
Actualitzar les referències, en cas d’existir, a mòduls propis de Terraform que apuntin a github.com per tal d’utilitzar el nou domini de GHEC amb data residency a Europa ctti.ghe.com. És important assegurar-se que totes les referències estiguin actualitzades per evitar errors durant el CI/CD de la infraestructura.
Generar els artefactes de cada component i les seves dependències
En aquesta migració no es contempla migrar a JFrog Artifactory els artefactes generats en els processos de CI/CD del tenant antic emmagatzemats a GitHub Packages. Per tant, en cas que hagin de ser consumits, serà necessari generar novament els artefactes de cada component i les seves dependències al nou tenant a partir del codi font.
Per a això, caldrà executar els workflows de CI a cada repositori per generar els artefactes i paquets necessaris, que s’emmagatzemaran a JFrog Artifactory segons la nova configuració. Per a llibreries NPM NOVES que es generin des del nou tenant d’Europa, caldrà eliminar el scope “@ctti-dev o @ctti-lab” al fitxer “package.json”. Per exemple, si es tenia una dependència com la següent:
"@ctti-dev/mylib": "1.0.0"
S’hauria de canviar a:
"mylib": "1.0.0"
Això s’aplica tant a llibreries com a imatges Docker, i qualsevol altre tipus d’artefacte generat en els processos de CI/CD.
Actualitzar les referències a artefactes, paquets i imatges de GitHub Packages
Si una imatge Docker que s’ha de construir depèn (FROM ghcr.io/…) d’una altra imatge també generada a través del SIC+, caldrà modificar la referència a aquesta imatge, que s’emmagatzemava prèviament a GitHub Packages per a que apunti a la nova ubicació a JFrog Artifactory (FROM ctti.jfrog.io/artifactory/repo-apps-docker/…)
Per a referències a llibreries de dependències Npm noves que es generin des del nou tenant d’Europa, caldrà eliminar el scope “@ctti-dev o @ctti-lab” al fitxer “package.json”. Per exemple, si es tenia una dependència com la següent:
"@ctti-dev/mylib": "1.0.0"
S’hauria de canviar a:
"mylib": "1.0.0"
Cal revisar el fitxer “package-lock.json” per eliminar qualsevol referència a GitHub Packages (https://npm.pkg.github.com). És molt important revisar aquest fitxer i eliminar qualsevol referència a GitHub Packages, ja que no es tindrà accés i la compilació per a buscar un paquet ja resolt prèviament en aquest repositori fallarà.
Actualitzar release.yml del repositori de test funcionals
En el release.yml del repositori de test funcionals cal substituir github.com per ctti.ghe.com per a apuntar a GitHub Europa.
Actualitzar comandos customs per a publicar librerias
Els comandos custom per a publicació de librerias java-maven canvia a:
mvn -B deploy -Dmaven.test.skip=true -DaltDeploymentRepository=jfrog-server::default::https://ctti.jfrog.io/artifactory/<JFROG_REPO_DEPLOY> -DdeployAtEnd=true
Substituint <JFROG_REPO_DEPLOY> pel nom del repositori de jfrog al qual s’ha de publicar la libreria. El nom del repositori es obtendra en executar el workflow de pull request, en el step de Setup JFrog CLI and Login aparecera com Target JFrog Repository
Per a la tecnologia Dotnet no és possible fer ús del comando custom de publicacion.
Regenerar tokens d’accés personal (PAT) i claus SSH
Els tokens d’accés personal (PAT) i les claus SSH utilitzades per a l’autenticació amb GitHub hauran de ser regenerats per assegurar que funcionin correctament al nou tenant.
Actualitzar el HOST al interactuar amb l’API o la CLI de GitHub
Revisar i actualitzar les referències a github.com als workflows per assegurar que apunten al nou domini ctti.ghe.com. Això s’ha de fer quan s’utilitza la CLI “gh” o l’API REST de GitHub, ja que normalment apunten per defecte a github.com. Una solució provada i recomanada és establir la variable d’entorn GH_HOST a ctti.ghe.com en els workflows, i fer l’assignació del GITHUB_TOKEN a la variable d’entorn GH_TOKEN, amb la qual cosa assegurem el canvi de host i l’autenticació correcta per interactuar amb l’API de GitHub al nou tenant.
echo "GH_HOST=ctti.ghe.com" >> $GITHUB_ENV
echo "GH_TOKEN=${{ secrets.GITHUB_TOKEN }}" >> $GITHUB_ENV
Actualització dels workflows reutilitzables a la release v5
Per a veure els canvis que incorpora aquesta nova versió v5 dels workflows reutilitzables accedir a l’enllaç RELEASE v5.
Guia d’actualització a la v5
La versió v5 dels workflows reutilitzables per al SIC+ s’alliberarà al Gener 2026 i estarà disponible per al seu ús en els repositoris migrats al nou tenant. Aquesta nova versió inclou una sèrie de millores i canvis que afectaran a les aplicacions existents. Per a facilitar la transició a la nova versió, s’ha preparat una guia d’actualització que detalla les passes necessaries a realitzar.
La guia d’actualització inclou informació sobre el procés a seguir, pas a pas, perquè els diferents components utilitzin la versió v5 dels workflows reutilitzables. Es recomana a tots els equips de desenvolupament que revisin aquesta guia i realitzin les actualitzacions necessàries en les seves aplicacions en la fase de migració ja que no es podrà usar la v4 al nou tenant.
Per cada repositori que utilitza els workflows reutilitzables, s’hauran de seguir els següents passos:
Pas a pas
Per a aquells repositoris que encara no hagin migrat de versió de reutilitzables, dependabot generarà automàticament una pull request d’avís perquè el Release Manager de l’aplicació sigui conscient que ha d’actualitzar les seves workflows a la versió indicada. AQUESTA PULL REQUEST DE DEPENDABOT ÉS ÚNICAMENT D’AVÍS I NO CAL ACCEPTAR-LA. El títol assignat serà una cosa similar a “Bump ctti-arq/reusable-workflows from 4 to 5”. Caldria seguir el procediment descrit a continuació:
- Crear una nova branca “feature/v5-update-develop” en el repositori del projecte a partir de la branca “develop”. Sobre aquesta branca es realitzaran els canvis necessaris per a l’actualització a la v5.
- Modificar en cada workflow definit en el repositori tota referència a la versió “v4” per la versió “v5”, mantenint la configuració de paràmetres anterior, a excepció dels paràmetres que han estat deprecats els quals hauran de ser eliminats o substituïts d’acord amb l’especificació descrita a la documentació de cada workflow: Configuració workflows. En aquest pas, es recomana revisar la documentació de cada workflow per a entendre els diferents paràmetres i els seus possibles valors.
- Una vegada fets els canvis, s’haurà de realitzar un commit i un push de la branca “feature/v5-update-develop” al repositori del projecte.
- Accedir a la pestanya de “Actions” del repositori i deshabilitar momentàniament els workflows que apareixen llistats, entrant a cadascun d’ells i usant l’opció “Disable workflow” en el botó “…”. Això és necessari per a evitar que s’executin automàticament els workflows en interactuar amb aquests fitxers mentre s’apliquen els canvis. Aquí s’adjunta la guia oficial de GitHub per a deshabilitar workflows: Deshabilitar workflows
- Realitzar una Pull Request (PR) de la branca “feature/v5-update-develop” a la branca “develop” del repositori del projecte només amb els canvis indicats en els passos anteriors. Es procedirà a revisar i aprovar la PR, i un cop aprovada s’iniciarà el procés d’integració del codi a la branca “develop”. Quan s’hagi realitzat la integració de codi a “develop” s’haurà d’esborrar aquesta branca “feature/v5-update-develop” per a evitar confusions i mantenir el repositori net.
- Una vegada es té el codi integrat a la branca “develop”, s’haurà de crear una nova branca “feature/v5-update-release” a partir de la branca “release” del repositori del projecte. Sobre aquesta branca es realitzaran els mismes canvis que en el pas 2. Un cop realitzats els canvis, s’haurà de fer un commit i un push de la branca “feature/v5-update-release” al repositori del projecte i se integrarà el codi aprovant una nova Pull Request a partir d’aquesta branca a la branca “release” esborrant després la branca “feature/v5-update-release”.
- Procedir de la mateixa manera que amb release però per a la branca “màster” creant una branca “feature/v5-update-master” a partir de la branca “master” del repositori del projecte, realitzant els canvis, fent commit i push, i integrant el codi mitjançant una Pull Request de la branca “feature/v5-update-master” a la branca “master”, esborrant després aquesta branca “feature/v5-update-master”. Amb això ens assegurem que els workflows estiguin definits i configurats en totes les branques protegides del repositori, amb tots els paràmetres informats i amb els valors correctes.
- Una vegada integrada la PR, s’haurà d’accedir novament a la pestanya de “Actions” del repositori i habilitar els workflows que es van deshabilitar en el pas 4. Per a això, s’haurà d’entrar a cadascun d’ells i usar l’opció “Enable workflow” en el botó “…”. Aquí s’adjunta la guia oficial de GitHub per a habilitar workflows: Habilitar workflows.
- A partir d’aquí ja es podria desestimar la Pull Request i i les branques generadas per dependabot com a avís i tancar-la.
Cal destacar que caldria tenir especial compte amb les branques de desenvolupament “feature/*” que existeixin en el repositori prèviament a l’actualització, ja que aquestes branques podrien contenir els workflows antics apuntant a la versió v4, i en intentar promocionar el codi a “develop” no adonar-se que s’estaria sobreescrivint la nova configuració dels workflows que s’ha realitzat.
Després de tots aquests canvis, els workflows reutilitzables estaran actualitzats a la versió v5 i es podran utilitzar en els repositoris de l’aplicació. Es recomana realitzar proves de funcionament dels workflows per a assegurar-se que tot està funcionant correctament i que no hi ha problemes de compatibilitat amb la nova versió. A més, es suggereix revisar la documentació de cada workflow per a entendre les noves funcionalitats i millores que s’han implementat en la v5.
Paràmetros deprecados
Paràmetres deprecados per a la v5 dels workflows reutilitzables. És necessari esborrar-los dels workflows per a evitar errors.
Workflows de CD d’Infraestructura, Contenidors, Funcions, Estaticos, DataBricks, DataFactory, APIManager i Executors
- repository_mat
- selenium_enabled
- selenium_urlapp
- selenium_llindar
- jira_project_key
- jira_issue_key
- itsm_enabled
Workflow de CI on PR d’Infraestructura
- checkov
- infracost
Workflow de CD Descriptors d’Executors
- vnet_name