(DRAFT) Migració al tenant de GitHub Enterprise Cloud with data residency

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.

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.

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ó.

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/docker-private/…).

Per a referències a dependències Npm que estaven a GitHub Packages, i es referenciaven amb l’scope “@ctti-lab” i “@ctti-dev”, caldrà eliminar aquest scope al fitxer “package.json”. Per exemple, si es tenia una dependència com la següent:

"@ctti-lab/mylib": "1.0.0"

S’hauria de canviar a:

"mylib": "1.0.0"

Cal revisar també el fitxer “package-lock.json” per eliminar qualsevol referència a l’scope “@ctti-lab” o “@ctti-dev”, si n’hi hagués.

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

1. Crear una nova branca “feature/v5-update” 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.
2. 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.
3. Una vegada fets els canvis, s’haurà de realitzar un commit i un push de la branca “feature/v5-update” al repositori del projecte.
4. 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
5. Realitzar una Pull Request (PR) de la branca “feature/v5-update” a la branca “develop” del repositori del projecte només amb els canvis indicats en els passos anteriors. Quan s’hagi realitzat la integració de codi a “develop” s’haurà d’esborrar aquesta branca “feature/v5-update” per a evitar confusions i mantenir el repositori net.
6. Una vegada es té el codi integrat a la branca “develop”, s’haurà de realitzar una nova Pull Request de la branca “develop” a la branca “release” del repositori del projecte. Es procedirà de la mateixa manera que en el pas anterior, fins que el codi estigui integrat en la branca “release”.
7. Repetir el pas anterior per a la branca “master” del repositori del projecte. En aquest cas, la Pull Request es realitzarà de la branca “release” a la branca “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.
8. 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 6. 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.

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.