Come risolvere "GitLab: API non accessibile" quando si preme su un nuovo repository?

7

abbiamo una Enterprise Edition di GitLab ospitata localmente presso la mia sede di servizio (attualmente v7.12.00-ee ceb5083). Posso creare un repository attraverso la GUI senza problemi. Ma quando provo ad aggiungere qualcosa al repository, ottengo questo errore:Come risolvere "GitLab: API non accessibile" quando si preme su un nuovo repository?

D:\ws\testing [master]> git push -u origin master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 219 bytes | 0 bytes/s, done. 
Total 3 (delta 0), reused 0 (delta 0) 
remote: GitLab: API is not accessible 
To http://gitlab.ops.cld/duffrw/testing.git 
! [remote rejected] master -> master (pre-receive hook declined) 
error: failed to push some refs to 'http://gitlab.ops.cld/duffrw/testing.git'

vedo nel file /var/log/gitlab/gitlab-shell/gitlab-shell.log che l'API non risponde, e sta dando un "Internal Server Error":

E, [2015-07-22T16:05:51.812454 #15110] ERROR -- : API call <POST http://127.0.0.1:8080/api/v3/internal/allowed> failed: 500 => <{"message":"500 Internal Server Error"}>.

Alcune domande ... Dove posso andare da qui? Ci deve essere un qualche tipo di fornitore di servizi che non è in esecuzione. Perchè no? Come si chiama? Come posso avviarlo?

ho controllato /var/log/gitlab/nginx/gitlab_access.log e hanno trovato queste righe, ma non ho visto nulla di interessante:

172.31.201.164 - - [22/Jul/2015:16:05:50 +0000] "GET /duffrw/testing.git/info/refs?service=git-receive-pack HTTP/1.1" 401 0 "-" "git/1.9.5.msysgit.1" 
172.31.201.164 - - [22/Jul/2015:16:05:50 +0000] "GET /duffrw/testing.git/info/refs?service=git-receive-pack HTTP/1.1" 401 0 "-" "git/1.9.5.msysgit.1" 
172.31.201.164 - duffrw [22/Jul/2015:16:05:51 +0000] "GET /duffrw/testing.git/info/refs?service=git-receive-pack HTTP/1.1" 200 179 "-" "git/1.9.5.msysgit.1" 
172.31.201.164 - duffrw [22/Jul/2015:16:05:51 +0000] "POST /duffrw/testing.git/git-receive-pack HTTP/1.1" 200 124 "-" "git/1.9.5.msysgit.1"

ma non ci sono errori per la spinta di questo repository in /var/log/gitlab/nginx/gitlab_error.log e /var/log/gitlab/nginx/error.log è completamente vuoto .

Cosa mi manca?

Aggiornamento:

Utilizzando il comando gitlab-ctl tail è molto comodo! Ha rivelato una traccia dello stack, che ho inviato a GitLab e mi hanno detto che si trattava di un bug in 7.12.00. È stato risolto in 7.13.00.

fonte

2015-07-22 Duff

+0

sei riuscito a risolverlo? Ho lo stesso errore nella stessa versione. – RayofCommand

+1

@RayofCommand, sì, l'ho fatto. Ho parlato per sostenere e mi hanno sistemato. Ho dovuto disattivare temporaneamente Git Hooks fino a quando non ho premuto, a quel punto ho riattivato i ganci. – Duff

6

È necessario impostare l'URL corretto per l'API GitLab nei file di configurazione di GitLab.

Come possiamo vedere nel vostro gitlab-shell.log il vostro indirizzo API è attualmente impostato su http://127.0.0.1:8080/. Se cambi l'URL predefinito in cui GitLab è in esecuzione o se hai cambiato la sua porta predefinita, devi cambiarlo.

Questo parametro è configurabile in /etc/gitlab/gitlab.rb:

## GitLab URL 
##! URL on which GitLab will be reachable. 
##! For more details on configuring external_url see: 
##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab 
external_url 'http://127.0.0.1:3000' 
[...]

Questo è il valore predefinito (come porta 3000 è il valore predefinito in GitLab omnibus per unicorn). Dopo averlo aggiornato, devi eseguire un sudo gitlab-ctl reconfigure per applicare questo parametro.

Sostituisce il file opt/gitlab/embedded/service/gitlab-shell/config.yml come indicato nei commenti di intestazione.

fonte

2015-07-23 11:23:28 PierreF

3

Abbiamo riscontrato questo problema quando ospitiamo il nostro gitlab su un "motore di calcolo" da google cloud. Il motivo di questo comportamento non era uno "scambio" configurato nella nostra macchina. Gitlab non è stato in grado di allocare memoria aggiuntiva.

Abbiamo deciso di scalare la nostra memoria, invece di creare una partizione di swap, ma è la vostra scelta ... :)

fonte

2016-04-19 12:08:13 fatel

0

Abbiamo incontrato questo spesso negli ultimi tempi. È sicuramente GitLab a corto di memoria. Non siamo ancora in grado di determinare se GitLab perde memoria o se l'istanza del nostro server è sottoposta a provisioning insufficiente.

fonte

2016-08-23 02:15:37

0

Ho avuto gli stessi problemi in Bitnami.Ho riavviato tutte le cose e risolto questo problema utilizzando

/opt/bitnami/ctlscript.sh restart

fonte

2016-09-07 09:18:29 user3346513

9

Se si utilizza gitlab.com, il server o è in fase di aggiornamento o di avere problemi.

È possibile controllare https://status.gitlab.com per gli aggiornamenti dal team GitLab.

C'è anche un account Twitter è possibile seguire: https://twitter.com/gitlabstatus

fonte

2016-12-21 05:49:43

+0

Questo dipende dal fatto che il server GitLab ufficiale sia utilizzato o che GitLab sia in esecuzione su un server indipendente e quale dei due stia aggiornando al momento, ma questo era il mio caso. – timelmer

+0

Ho visto questo problema adesso, e sì gitlab.com mostra che è in manutenzione, questa potrebbe essere la vera ragione! –

+0

E puoi vedere lo stato di gitlab.com tramite https://twitter.com/gitlabstatus –

1

Riavviare il servizio gitlab risolvere il mio problema.

sudo gitlab-ctl restart 

sudo gitlab-ctl reconfigure

fonte

2017-01-06 10:34:43

Come risolvere "GitLab: API non accessibile" quando si preme su un nuovo repository?

risposta

Problemi correlati