Saltar al contenido principal

Solución de problemas

El runner muestra el error 404​

Cómo solucionarlo​

Obtención del código de error 401 desde el runner

Problema de Gathering Facts para localhost​

El problema puede producirse en Semaphore UI instalado mediante Snap o Docker.

4:10:16 PM
TASK [Gathering Facts] *********************************************************
4:10:17 PM
fatal: [localhost]: FAILED! => changed=false

Por qué ocurre​

Para más información sobre el uso de localhost en Ansible, lea este artículo: Implicit 'localhost'.

Ansible intenta recopilar los facts localmente, pero Ansible se encuentra en un contenedor aislado y limitado que no lo permite.

Cómo solucionarlo​

Hay dos formas:

  1. Desactivar la recopilación de facts:
- hosts: localhost
  gather_facts: False
  roles:
    - ...
  1. Establecer explícitamente el tipo de conexión en ssh:
[localhost]
127.0.0.1 ansible_connection=ssh ansible_ssh_user=your_localhost_user

panic: pq: SSL is not enabled on the server​

Esto significa que su Postgres no funciona con SSL.

Cómo solucionarlo​

Añada la opción sslmode=disable al archivo de configuración:

	"postgres": {
		"host": "localhost",
		"user": "postgres",
		"pass": "pwd",
		"name": "semaphore",
		"options": {
			"sslmode": "disable"
		}
	},

fatal: bad numeric config value '0' for 'GIT_TERMINAL_PROMPT': invalid unit​

Esto significa que está intentando acceder a un repositorio a través de HTTPS que requiere autenticación.

Cómo solucionarlo​

  • Vaya a la pantalla Almacén de claves.
  • Cree una nueva clave de tipo Login with password.
  • Indique su usuario de GitHub/BitBucket/etc.
  • Indique la contraseña. No puede usar la contraseña de su cuenta de GitHub/BitBucket; en su lugar debe usar un Personal Access Token (PAT). Lea más aquí.
  • Tras crear la clave, vaya a la pantalla Repositorios, busque su repositorio e indique la clave.

El clone o pull de Git falla de forma intermitente​

Los registros de la tarea pueden mostrar mensajes como Git pull failed (...), retrying in 2s seguidos de un éxito o de un fallo definitivo tras varios intentos.

Por qué ocurre​

El servidor git (GitHub, GitLab, Bitbucket o una instancia autoalojada) estuvo temporalmente inaccesible, devolvió un error HTTP transitorio, o la red entre Semaphore y el servidor sufrió una breve interrupción. Semaphore reintenta automáticamente las operaciones de clone y pull antes de marcar la tarea como fallida.

Cómo solucionarlo​

  1. Interrupciones transitorias: normalmente se resuelven por sí solas. Semaphore reintenta hasta git_attempts veces (4 de forma predeterminada) con retroceso exponencial entre intentos.
  2. Fallos frecuentes: aumente el número de intentos en su configuración:
{
  "git_attempts": 8
}

O con una variable de entorno:

export SEMAPHORE_GIT_ATTEMPTS=8
  1. Fallos inmediatos y constantes: los reintentos no ayudarán. Compruebe la URL del repositorio, el nombre de la rama, las claves de acceso y la conectividad de red desde el servidor de Semaphore o el host del runner.

Consulte Operaciones de Git para más detalles sobre git_client y git_attempts.

La salida del script Bash falta o está incompleta​

Una tarea Bash termina correctamente, pero el registro muestra poca o ninguna salida de echo, printf u otros comandos, especialmente cuando el script finaliza rápidamente.

Por qué ocurre​

Semaphore captura stdout y stderr de los comandos de shell mientras se ejecutan. Los scripts muy cortos pueden terminar antes de que se lea toda la salida almacenada en el búfer, por lo que las últimas líneas pueden perderse en el registro de la tarea.

Cómo solucionarlo​

  1. Actualice: las versiones recientes de Semaphore vacían la salida del proceso antes de marcar una tarea como completada. Actualice el servidor y los runners si usa una versión antigua.
  2. Vacíe la salida en el script cuando necesite garantizar su entrega:
#!/bin/bash
echo "Starting deploy"
echo "Done" >&2

Para diagnósticos críticos, escriba en un archivo dentro del espacio de trabajo del repositorio y haga cat de él al final del script. 3. Evite salidas anticipadas silenciosas: use set -euo pipefail y mensajes de error explícitos para que los fallos sean visibles incluso cuando la salida sea breve.

unable to read LDAP response packet: unexpected EOF​

Lo más probable es que esté intentando conectarse al servidor LDAP con un método inseguro, aunque este espera una conexión segura (mediante TLS).

Cómo solucionarlo​

Habilite TLS en su archivo config.json:

...
"ldap_needtls": true
...

LDAP Result Code 49 "Invalid Credentials"​

Tiene una contraseña o un binddn incorrectos.

Cómo solucionarlo​

Use la herramienta ldapwhoami y compruebe si su binddn funciona:

ldapwhoami\
  -H ldap://ldap.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -x\
  -W

Le pedirá la contraseña de forma interactiva y debería devolver el código 0 y mostrar el DN especificado.

También puede leer los siguientes artículos:

LDAP Result Code 32 "No Such Object"​

El directorio no tiene ninguna entrada en el nombre distinguido por el que preguntó Semaphore. Casi siempre se debe a un ldap_searchdn incorrecto y, con menos frecuencia, a un ldap_binddn incorrecto.

Cómo solucionarlo​

Compruebe que la base de búsqueda existe, usando las mismas credenciales que usa Semaphore:

ldapsearch\
  -H ldap://ldap.example.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -b "/your/ldap_searchdn/value/in/config/file"\
  -x\
  -W\
  -s base
  • El código de resultado 32 de este comando significa que la propia base no existe. Corrija ldap_searchdn en config.json; la causa habitual es una errata en algún componente, como OU=Users frente al OU=People real.
  • El código de resultado 0 significa que la base es correcta y que el problema está en ldap_searchfilter: no coincide con ninguna entrada por debajo de esa base.

Consulte LDAP y AD para conocer el significado de cada opción.