Hands-on Lab

Cómo actualizar Gitea 1.27 a 28 con Docker sin perder los webhooks

21 de octubre de 2026 4 min

0 / 8

Chuleta

¿Te ha servido? No te pierdas el próximo lab

El vídeo tiene subtítulos y transcripción. Todo lo que se ve está escrito, paso a paso, más abajo. Chuleta con todos los comandos

0:00 / 0:00

Fijamos GITEA_TAG=1.27.3 en el .env y la imagen oficial docker.gitea.com/gitea lo lee con ${GITEA_TAG}. INSTALL_LOCK=true salta el asistente web de instalación y DB_TYPE=sqlite3 guarda la base de datos dentro del volumen gitea_data. Las dos claves ALLOWED_HOST_LIST=private reproducen una 1.27 típica: la de [security] y la heredada de [webhook]. El servicio hook es un nginx que recibe los webhooks dentro de la red de Compose.

mkdir -p /root/gitea && cd /root/gitea && echo 'GITEA_TAG=1.27.3' > .env && cat > docker-compose.yml <<'EOF'
services:
  gitea:
    image: docker.gitea.com/gitea:${GITEA_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      GITEA__database__DB_TYPE: sqlite3
      GITEA__security__INSTALL_LOCK: "true"
      GITEA__security__ALLOWED_HOST_LIST: private
      GITEA__webhook__ALLOWED_HOST_LIST: private
    ports:
      - "3000:3000"
    volumes:
      - gitea_data:/data
  hook:
    image: nginx:1.29-alpine
volumes:
  gitea_data:
EOF
docker compose up -d --quiet-pull

Lo hice yo

Esperamos en un bucle de hasta 120 s a que /api/healthz conteste, la señal real de que Gitea ya sirve peticiones, y pedimos la versión a la API. El registro de arranque muestra un aviso de obsolescencia: la clave ALLOWED_HOST_LIST de [webhook] dejará de leerse en la v28.0.0.

cd /root/gitea && for i in $(seq 1 60); do curl -sf http://localhost:3000/api/healthz >/dev/null && break; sleep 2; done; curl -s http://localhost:3000/api/healthz | jq -r '"healthz: " + .status'; curl -s http://localhost:3000/api/v1/version; echo; docker compose logs gitea | grep -m1 -o 'Deprecation: config option .\[webhook\].ALLOWED_HOST_LIST. present'; docker compose logs gitea | grep -m1 -o 'removed in v28.0.0'

Qué demuestra

healthz: pass el endpoint de salud de Gitea responde pass Objetivo · sabes que la instancia está lista antes de crear nada
{"version":"1.27.3"} la API informa de la versión 1.27.3, la del .env Objetivo · tienes el punto de partida de la actualización confirmado
removed in v28.0.0 la 1.27.3 avisa de que la clave de [webhook] se elimina en la 28 Objetivo · sabes qué línea de app.ini hay que limpiar antes de actualizar

gitea admin user create crea la cuenta sin pasar por la web. La ejecutamos con -u git porque Gitea corre como ese usuario dentro de la imagen, y así lo que toque la CLI sigue siendo suyo. La contraseña changeme es de prueba y --must-change-password=false nos deja usarla en la API sin cambiarla.

cd /root/gitea && docker compose exec -u git gitea gitea admin user create --admin --username labadmin --password changeme --email labadmin@lab.local --must-change-password=false

Lo hice yo

Listamos solo las cuentas de administrador. labadmin aparece con su correo y IsActive a true, así que ya podemos autenticarnos en la API con ella.

cd /root/gitea && docker compose exec -u git gitea gitea admin user list --admin

Qué demuestra

labadmin@lab.local la cuenta labadmin existe con su correo Objetivo · tienes un usuario con el que crear el repositorio y el webhook

POST /user/repos crea demo con un primer commit (auto_init). POST /repos/labadmin/demo/hooks registra un webhook de tipo gitea que avisa en cada push a http://hook/ci, el nginx de la red de Compose, una IP privada que ALLOWED_HOST_LIST=private permite. POST /hooks/1/tests pide a Gitea una entrega de prueba y responde 204.

cd /root/gitea && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/user/repos -d '{"name":"demo","auto_init":true}' | jq -c '{full_name,default_branch}' && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks -d '{"type":"gitea","config":{"url":"http://hook/ci","content_type":"json"},"events":["push"],"active":true}' | jq -c '{id,active,url:.config.url}' && curl -s -o /dev/null -w 'test delivery: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/1/tests

Lo hice yo

La entrega es asíncrona, así que esperamos hasta 30 s a que aparezca en el registro de acceso del nginx. El 404 es del nginx, que no tiene ninguna página en /ci: lo que cuenta es que la petición de Gitea llegó a su destino en la red interna.

cd /root/gitea && for i in $(seq 1 30); do docker compose logs hook | grep -q 'POST /ci' && break; sleep 1; done; echo "deliveries: $(docker compose logs hook | grep -c 'POST /ci.*Go-http-client')"; docker compose logs hook | grep -m1 -o '"POST /ci HTTP/1.1" 404 .*Go-http-client/1.1'

Qué demuestra

deliveries: 1 el nginx registra 1 petición POST a /ci Objetivo · tienes un webhook que entrega en la 1.27.3, la referencia para comparar tras la actualización
Go-http-client/1.1 la petición la envía el cliente HTTP de Gitea Objetivo · descartas que la entrada del registro venga de otro sitio

La documentación de Gitea pide parar la instancia antes de copiar, porque la base de datos y los repositorios cambian a la vez. Con SQLite, la base de datos vive dentro de /data, así que el tar del volumen guarda repositorios, app.ini y base de datos en un solo fichero. El volumen se llama gitea_gitea_data: el nombre del proyecto de Compose más el del volumen.

cd /root/gitea && docker compose stop gitea && mkdir -p backup && docker run --rm -q -v gitea_gitea_data:/data:ro -v "$PWD/backup":/backup alpine:3.22 tar czf /backup/gitea-data-1.27.3.tar.gz -C /data .

Lo hice yo

Comprobamos que el contenedor está en estado exited, así que nada escribía mientras copiábamos, y listamos el contenido del archivo: la configuración, la base de datos SQLite y el repositorio demo. Con esa copia, volver a la 1.27.3 es restaurar el volumen y la etiqueta.

cd /root/gitea && docker compose ps -a gitea --format '{{.Service}} {{.State}}' && ls -lh backup && tar tzf backup/gitea-data-1.27.3.tar.gz | grep -E 'app.ini|gitea.db|demo.git/HEAD'

Qué demuestra

gitea exited el servicio gitea está parado Objetivo · sabes que la copia es coherente, sin escrituras a medias
./gitea/gitea.db la base de datos SQLite está dentro del archivo Objetivo · tienes todo lo necesario para volver atrás si la 28 falla

El sed borra las claves de egress que la 28 da por obsoletas, y la de [webhook] solo dentro de su sección, para no tocar la de [security]. En el Compose quitamos la variable de [webhook], porque environment-to-ini la volvería a escribir. En su lugar ponemos EGRESS_MODE=strict, que en la 28 solo deja salir webhooks hacia los hosts de la lista.

cd /root/gitea && docker run --rm -q -v gitea_gitea_data:/data alpine:3.22 sed -i -e '/^ALLOW_LOCALNETWORKS/d' -e '/^ALLOWED_DOMAINS/d' -e '/^BLOCKED_DOMAINS/d' -e '/^\[webhook\]/,/^\[/{/^ALLOWED_HOST_LIST/d}' /data/gitea/conf/app.ini && sed -i 's/GITEA__webhook__ALLOWED_HOST_LIST: private/GITEA__security__EGRESS_MODE: strict/' docker-compose.yml

Lo hice yo

Contamos las ALLOWED_HOST_LIST que quedan en app.ini y cuántas hay dentro de [webhook], y revisamos las variables de [security] del Compose. Así arrancamos la 28 sin la clave que ya no lee.

cd /root/gitea && docker run --rm -q -v gitea_gitea_data:/data:ro alpine:3.22 sh -c 'grep -n "^ALLOWED_HOST_LIST" /data/gitea/conf/app.ini; echo "[webhook] ALLOWED_HOST_LIST: $(sed -n "/^\[webhook\]/,/^\[/p" /data/gitea/conf/app.ini | grep -c ALLOWED_HOST_LIST)"'; grep -n 'GITEA__security' docker-compose.yml

Qué demuestra

[webhook] ALLOWED_HOST_LIST: 0 la sección [webhook] ya no tiene ALLOWED_HOST_LIST Objetivo · la 28 no encontrará la clave obsoleta al arrancar
GITEA__security__EGRESS_MODE: strict el Compose fija EGRESS_MODE strict en [security] Objetivo · preparas la 28 para entregar solo a los hosts de la lista

La actualización es una línea del .env. docker compose pull descarga docker.gitea.com/gitea:28.0.0 y up -d recrea solo el servicio gitea con la imagen nueva y el mismo volumen.

cd /root/gitea && sed -i 's/^GITEA_TAG=.*/GITEA_TAG=28.0.0/' .env && cat .env && docker compose pull -q gitea && docker compose up -d gitea

Lo hice yo

Gitea aplica las migraciones de la base de datos al arrancar, antes de servir HTTP, así que esperamos otra vez a /api/healthz. Contamos las migraciones del registro, de la 343 a la 355, y las líneas [E] o [F]: con app.ini limpio no aparece ni el aviso de obsolescencia ni ningún error.

cd /root/gitea && for i in $(seq 1 60); do curl -sf http://localhost:3000/api/healthz >/dev/null && break; sleep 2; done; curl -s http://localhost:3000/api/v1/version; echo; echo "migrations: $(docker compose logs gitea | grep -c 'Migration\[')"; docker compose logs gitea | grep -m1 -o 'Migration\[343\].*'; docker compose logs gitea | grep -m1 -o 'Migration\[355\].*'; echo "errors: $(docker compose logs gitea | grep -cE '\[(E|F)\]')"

Qué demuestra

{"version":"28.0.0"} la API informa de la versión 28.0.0 Objetivo · confirmas que la actualización se ha aplicado
migrations: 13 Gitea aplicó 13 migraciones de esquema Objetivo · sabes que la base de datos ya no sirve para la 1.27.3 sin la copia
errors: 0 el registro de la 28 no tiene líneas [E] ni [F] Objetivo · compruebas que la limpieza de app.ini evitó avisos y fallos de arranque

Lanzamos otra entrega de prueba del webhook 1, el que creamos en la 1.27.3. Después registramos un webhook 2 hacia https://example.com/ci para ver qué hace EGRESS_MODE=strict con un host público fuera de ALLOWED_HOST_LIST. Las dos peticiones de prueba responden 204: Gitea encola la entrega y la intenta después.

cd /root/gitea && curl -s -o /dev/null -w 'LAN hook test: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/1/tests && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks -d '{"type":"gitea","config":{"url":"https://example.com/ci","content_type":"json"},"events":["push"],"active":true}' | jq -c '{id,url:.config.url}' && curl -s -o /dev/null -w 'public hook test: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/2/tests

Lo hice yo

La API de la 28.0.0 devuelve el repositorio labadmin/demo y los dos webhooks. El registro del nginx suma ahora 2 entregas, la de la 1.27.3 y la de la 28, así que el webhook sobrevivió a la actualización y sigue llegando a la red interna. La entrega a example.com falla con denied by egress policy, porque en modo strict un host público fuera de la lista no recibe nada.

cd /root/gitea && curl -s http://localhost:3000/api/v1/version; echo; curl -s -u labadmin:changeme http://localhost:3000/api/v1/repos/labadmin/demo | jq -r '"repo: " + .full_name'; curl -s -u labadmin:changeme http://localhost:3000/api/v1/repos/labadmin/demo/hooks | jq -r '.[] | "hook \(.id): \(.config.url)"'; for i in $(seq 1 30); do [ "$(docker compose logs hook | grep -c 'POST /ci.*Go-http-client')" -ge 2 ] && docker compose logs gitea | grep -q 'denied by egress policy' && break; sleep 1; done; echo "LAN deliveries: $(docker compose logs hook | grep -c 'POST /ci.*Go-http-client')"; docker compose logs gitea | grep -m1 -o 'https://example.com/ci": dial tcp .*denied by egress policy'

Qué demuestra

repo: labadmin/demo el repositorio creado en la 1.27.3 sigue en la 28 Objetivo · compruebas que la actualización no perdió datos
LAN deliveries: 2 el nginx recibió una segunda entrega, ya desde la 28 Objetivo · sabes que el webhook de la red interna sigue funcionando tras actualizar
denied by egress policy la 28 bloquea la entrega a example.com con EGRESS_MODE strict Objetivo · confirmas que la lista de hosts sigue siendo exclusiva en la 28

docker compose down para y elimina los contenedores gitea y hook y la red del proyecto, y -v borra también el volumen gitea_gitea_data. La copia en backup/ queda en el disco, fuera de Docker.

cd /root/gitea && docker compose down -v

Lo hice yo

Contamos los contenedores y los volúmenes de Gitea que quedan: 0 en ambos casos. El archivo gitea-data-1.27.3.tar.gz sigue en backup/, que es lo que conservarías en un servidor real.

cd /root/gitea && echo "containers: $(docker ps -aq | wc -l)"; echo "gitea volumes: $(docker volume ls -q | grep -c gitea_data)"; ls backup

Qué demuestra

containers: 0 no queda ningún contenedor Objetivo · dejas la máquina como estaba antes del lab
gitea volumes: 0 el volumen de Gitea se ha borrado Objetivo · sabes que down -v también eliminó los datos persistentes

¿Te ha sido útil este lab? Puntúalo:

Click to rate this post!

[Total: 0 Average: 0]

Transcripción del vídeo

0:00 Gitea 28 en Docker, con el repositorio y el webhook de la 1.27 intactos.
0:08 Escribimos el Compose de Gitea 1.27.3.
0:12 La versión va en el fichero de entorno, con SQLite y un nginx que recibirá los
0:17 webhooks.
0:19 La versión vive en una sola línea del fichero .env, y el Compose la lee al
0:24 arrancar.
0:26 Llevamos Gitea de la 1.27.3 a la 28.0.0 sin perder el repositorio ni el webhook.
0:32 En la 28 cambian la salida de los webhooks, las claves de app.ini y el
0:37 esquema.
0:39 Con healthz en pass, la API da la 1.27.3, y el registro avisa de que la clave de
0:45 [webhook] desaparece en la 28.
0:49 Creamos el administrador labadmin con la CLI de Gitea, como usuario git dentro del
0:55 contenedor.
0:57 Lo comprobamos:
0:58 la lista de administradores incluye a labadmin, activo.
1:05 Por la API creamos el repositorio demo y un webhook hacia el nginx, y lanzamos una
1:11 entrega de prueba.
1:13 El nginx registra 1 entrega a /ci desde el cliente HTTP de Gitea.
1:21 El orden importa:
1:23 parar, copiar, limpiar app.ini y solo entonces cambiar la etiqueta.
1:28 Paramos Gitea y archivamos el volumen con tar desde un contenedor alpine, en solo
1:33 lectura.
1:35 Gitea está parado y la copia contiene app.ini, la base de datos y el repositorio
1:41 demo.
1:45 El script de arranque de la imagen escribe cada variable GITEA en app.ini y nunca
1:51 borra ninguna.
1:53 Borramos de app.ini las claves heredadas con el sed del artículo, y en el Compose
1:59 ponemos EGRESS_MODE strict.
2:02 En app.ini queda una sola ALLOWED_HOST_LIST, la de [security], y
2:08 ninguna en [webhook].
2:12 Cambiamos GITEA_TAG a 28.0.0 en el .env, descargamos la imagen nueva y
2:17 recreamos el contenedor.
2:20 La API ya da la 28.0.0, con 13 migraciones de esquema y 0 errores en
2:26 el registro.
2:31 En la 28, EGRESS_MODE decide si la lista de hosts es exclusiva o solo protege la
2:36 red interna.
2:39 Probamos el webhook interno y creamos otro hacia example.com, un host público fuera
2:44 de la lista.
2:47 En la 28 siguen el repositorio y el webhook, que suma 2 entregas.
2:52 El de example.com queda denegado por la política de salida.
2:58 Bajamos el proyecto y borramos su volumen con docker compose down -v.
3:05 No quedan contenedores ni volumen, y la copia sigue en el disco.

Este lab reproduce en terminal la guía para actualizar Gitea 28 con Docker: partimos de Gitea 1.27.3 en Docker Compose, con la versión fijada en GITEA_TAG dentro del .env, y lo llevamos a la 28.0.0 sin perder el repositorio ni el webhook. Si aún no tienes Gitea, empieza por cómo instalar Gitea con Docker.

Qué cambia al pasar de Gitea 1.27 a 28

Gitea 28.0.0 es la versión que sigue a la 1.27.3: el anuncio oficial de Gitea 28.0.0 explica que el proyecto quitó el prefijo 1. de la numeración. En Docker cambia una línea del .env, pero la 28 aplica 13 migraciones de esquema y cambia cómo salen los webhooks: pasan por una política de salida, EGRESS_MODE, que en modo strict solo entrega a los hosts de ALLOWED_HOST_LIST. El cambio llegó con el PR 39426 de Gitea.

Qué demuestra la captura

Cada paso del vídeo se ejecutó de verdad. La captura deja cuatro pruebas:

la API pasa de {"version":"1.27.3"} a {"version":"28.0.0"}
la 28 registra 13 migraciones, de la 343 a la 355, y 0 líneas de error
el repositorio labadmin/demo y el webhook hacia el nginx de la red interna siguen ahí, y el nginx cuenta 2 entregas, una por versión
con EGRESS_MODE=strict, un webhook a example.com queda denegado con denied by egress policy

La copia de seguridad, con Gitea parado

La documentación de copias de seguridad de Gitea pide parar la instancia antes de copiar. El lab usa SQLite, así que la base de datos vive en el volumen /data y un solo tar guarda repositorios, app.ini y base de datos. El artículo original usa PostgreSQL y añade un pg_dump; si quieres practicar el patrón de copia y restauración, lo tienes en el lab de copias de seguridad de volúmenes Docker.

Por qué el sed sobre app.ini

El script de arranque de la imagen escribe cada variable GITEA__ en app.ini y nunca borra nada. Por eso la clave heredada [webhook] ALLOWED_HOST_LIST sigue en el fichero aunque la quites del Compose, y la 1.27.3 ya avisa al arrancar de que se elimina en la v28.0.0. El lab la borra con el mismo sed del artículo, con Gitea parado. La sustitución de ${GITEA_TAG} es la interpolación de variables de Docker Compose; si Compose es nuevo para ti, repasa el lab de aplicaciones multicontenedor con Docker Compose.

Lo que este lab no cubre

El artículo prueba además mirrors, la retención de 400 días de Actions con RUN_RETENTION_DAYS, el bucle de reinicios por un comodín en BLOCKED_DOMAINS y la vuelta atrás con pg_restore. Aquí no los repetimos: consulta esas secciones en la guía antes de actualizar una instancia con esos elementos, y la guía oficial de actualización de Gitea.

Preguntas frecuentes

¿Por qué Gitea pasa de la 1.27 a la 28 y no a la 1.28?

El proyecto quitó el prefijo histórico 1. de la numeración, así que la versión que sigue a la 1.27.3 es la 28.0.0. En Docker solo cambia la etiqueta de la imagen: docker.gitea.com/gitea:28.0.0.

¿Hace falta parar Gitea para hacer la copia de seguridad?

Sí. La documentación de Gitea pide parar la instancia antes de copiar, porque la base de datos y los repositorios cambian a la vez. En este lab paramos el servicio con docker compose stop gitea y archivamos el volumen con tar desde un contenedor alpine montado en solo lectura.

¿Por qué hay que limpiar app.ini si ya he cambiado el docker-compose.yml?

Porque el script de arranque de la imagen escribe cada variable GITEA__ en app.ini y nunca borra ninguna. La clave [webhook] ALLOWED_HOST_LIST sigue en el fichero aunque la quites del Compose, y la 1.27.3 ya avisa de que la 28 deja de leerla.

¿Puedo volver a Gitea 1.27 después de actualizar?

Solo restaurando la copia. La 28.0.0 aplica 13 migraciones de esquema al arrancar y, como muestra la guía original, la 1.27.3 se niega a arrancar sobre una base de datos migrada. Restaura el volumen desde el tar, devuelve GITEA_TAG a 1.27.3 y arranca otra vez.

Chuleta

mkdir -p /root/gitea && cd /root/gitea && echo 'GITEA_TAG=1.27.3' > .env && cat > docker-compose.yml <<'EOF'
services:
  gitea:
    image: docker.gitea.com/gitea:${GITEA_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      GITEA__database__DB_TYPE: sqlite3
      GITEA__security__INSTALL_LOCK: "true"
      GITEA__security__ALLOWED_HOST_LIST: private
      GITEA__webhook__ALLOWED_HOST_LIST: private
    ports:
      - "3000:3000"
    volumes:
      - gitea_data:/data
  hook:
    image: nginx:1.29-alpine
volumes:
  gitea_data:
EOF
docker compose up -d --quiet-pull

cd /root/gitea && docker compose exec -u git gitea gitea admin user create --admin --username labadmin --password changeme --email labadmin@lab.local --must-change-password=false

cd /root/gitea && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/user/repos -d '{"name":"demo","auto_init":true}' | jq -c '{full_name,default_branch}' && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks -d '{"type":"gitea","config":{"url":"http://hook/ci","content_type":"json"},"events":["push"],"active":true}' | jq -c '{id,active,url:.config.url}' && curl -s -o /dev/null -w 'test delivery: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/1/tests

cd /root/gitea && docker compose stop gitea && mkdir -p backup && docker run --rm -q -v gitea_gitea_data:/data:ro -v "$PWD/backup":/backup alpine:3.22 tar czf /backup/gitea-data-1.27.3.tar.gz -C /data .

cd /root/gitea && docker run --rm -q -v gitea_gitea_data:/data alpine:3.22 sed -i -e '/^ALLOW_LOCALNETWORKS/d' -e '/^ALLOWED_DOMAINS/d' -e '/^BLOCKED_DOMAINS/d' -e '/^\[webhook\]/,/^\[/{/^ALLOWED_HOST_LIST/d}' /data/gitea/conf/app.ini && sed -i 's/GITEA__webhook__ALLOWED_HOST_LIST: private/GITEA__security__EGRESS_MODE: strict/' docker-compose.yml

cd /root/gitea && sed -i 's/^GITEA_TAG=.*/GITEA_TAG=28.0.0/' .env && cat .env && docker compose pull -q gitea && docker compose up -d gitea

cd /root/gitea && curl -s -o /dev/null -w 'LAN hook test: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/1/tests && curl -s -u labadmin:changeme -H 'Content-Type: application/json' -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks -d '{"type":"gitea","config":{"url":"https://example.com/ci","content_type":"json"},"events":["push"],"active":true}' | jq -c '{id,url:.config.url}' && curl -s -o /dev/null -w 'public hook test: %{http_code}\n' -u labadmin:changeme -X POST http://localhost:3000/api/v1/repos/labadmin/demo/hooks/2/tests

cd /root/gitea && docker compose down -v

¿Te ha servido? No te pierdas el próximo lab

Suscríbete a la newsletter

Qué cambia al pasar de Gitea 1.27 a 28

Qué demuestra la captura

La copia de seguridad, con Gitea parado

Por qué el sed sobre app.ini

Lo que este lab no cubre

Preguntas frecuentes

¿Por qué Gitea pasa de la 1.27 a la 28 y no a la 1.28?

¿Hace falta parar Gitea para hacer la copia de seguridad?

¿Por qué hay que limpiar app.ini si ya he cambiado el docker-compose.yml?

¿Puedo volver a Gitea 1.27 después de actualizar?

Chuleta