Erreur Git lors de la reconstruction de l'application - impossible de trouver la référence distante refs/heads/tests-passed

Salut tout le monde,

J’obtiens cette erreur lorsque je reconstruis l’application

> Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
>   set -o errexit
>   if [ $(git rev-parse --is-shallow-repository) == "true" ]; then
>       git remote set-branches --add origin main
>       git remote set-branches origin tests-passed
>       git fetch --depth 1 origin tests-passed
>   else
>       git fetch --tags --prune-tags --prune --force origin
>   fi
> ' failed with return #<Process::Status: pid 145 exit 128>

Lorsque j’exécute ceci :

> git fetch --tags --prune-tags --prune --force origin

J’obtiens l’erreur :

> fatal: couldn't find remote ref refs/heads/tests-passed

Est-ce que je fais quelque chose de mal ?

Merci et à bientôt !

P.S. J’ai oublié de mentionner. Le premier checkout a fonctionné, seule la tâche de reconstruction de l’application échoue avec cela. Donc pas de problème Git de mon côté, je pense (j’espère :slight_smile: )

Je viens de remarquer d’autres problèmes dans les logs :frowning:

Mises à jour réussies. Reconstruction dans 5 secondes.
Construction de l’application
Architecture x86_64 détectée.
Assurer la mise à jour du lanceur
fatal: impossible de trouver la référence distante refs/heads/tests-passed
fatal: la branche parente ‘refs/heads/main’ n’est pas stockée en tant que branche de suivi distant
fatal: la branche parente ‘refs/heads/main’ n’est pas stockée en tant que branche de suivi distant
./launcher: ligne 794: [: 69d7558c98a3775f62b720a8393e76f2b42bd916: opérateur unaire attendu
./launcher: ligne 797: [: 69d7558c98a3775f62b720a8393e76f2b42bd916: opérateur unaire attendu

Lorsque j’exécute un conteneur avec docker run -it --entrypoint /bin/bash …
et que j’essaie d’utiliser git, j’obtiens ceci

git clone https://github.com/discourse/discourse.git/
Clonage dans le répertoire 'discourse'...
fatal: impossible d'accéder à 'https://github.com/discourse/discourse.git/': la vérification du certificat du serveur a échoué. CAfile: none CRLfile: none

Pouvez-vous s’il vous plaît poster la sortie complète du journal et utiliser un bloc de code préformaté ? cela aiderait.

Je soupçonne que vous faites cela sur un réseau d’entreprise qui utilise un proxy d’inspection MITM pour le trafic web sortant ?

Si c’est le cas, vous devrez configurer votre serveur (et l’image Docker) pour qu’il approuve votre certificat racine d’autorité de certification d’entreprise.

C’est exactement le cas.
Existe-t-il une fonctionnalité standard disponible dans Discourse Docker pour y parvenir (je veux dire l’image Docker, pas le serveur), ou dois-je le faire manuellement ?

Merci d’avance et salutations,

WS

Mise à jour : Non, je me trompais. Je fais en fait cela dans un contexte d’entreprise, mais l’instance est sur une instance EC2 (Amazon Linux 2 AMI standard), qui peut sortir via un proxy …
Et, comme je l’ai dit, le premier checkout a été un succès, seul le rebuild échoue.

Vérifié à nouveau, ça fonctionne sur l’hôte, mais pas dans le conteneur :frowning:

Salut @Lilly , désolé pour le délai, mais voici le journal (la partie pertinente, je suppose)

I, [2024-11-20T05:57:07.498456 #1]  INFO -- : > cd /var/www/discourse && sudo -H -E -u discourse git reset --hard
Mise à jour des fichiers : 100% (34680/34680), terminé.
I, [2024-11-20T05:57:11.943323 #1]  INFO -- : HEAD est maintenant à 274e18622 FIX : Les téléchargements vidéo se bloquent parfois indéfiniment (#28523)

I, [2024-11-20T05:57:11.943867 #1]  INFO -- : > cd /var/www/discourse && sudo -H -E -u discourse git clean -f
I, [2024-11-20T05:57:12.079705 #1]  INFO -- : 
I, [2024-11-20T05:57:12.080107 #1]  INFO -- : > cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  if [ $(git rev-parse --is-shallow-repository) == "true" ]; then
      git remote set-branches --add origin main
      git remote set-branches origin tests-passed
      git fetch --depth 1 origin tests-passed
  else
      git fetch --tags --prune-tags --prune --force origin
  fi
'
fatal: impossible d'accéder à 'https://github.com/discourse/discourse.git/': la vérification du certificat du serveur a échoué. CAfile: none CRLfile: none
I, [2024-11-20T05:57:12.186392 #1]  INFO -- : 
I, [2024-11-20T05:57:12.187130 #1]  INFO -- : Arrêt des processus asynchrones
I, [2024-11-20T05:57:12.187180 #1]  INFO -- : Envoi de INT à HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 39
2024-11-20 05:57:12.187 UTC [39] LOG : demande d'arrêt rapide reçue
I, [2024-11-20T05:57:12.187839 #1]  INFO -- : Envoi de TERM à exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 107
107:signal-handler (1732082232) SIGTERM reçu, planification de l'arrêt...
2024-11-20 05:57:12.189 UTC [39] LOG : annulation de toutes les transactions actives
107:M 20 Nov 2024 05:57:12.193 # Arrêt demandé par l'utilisateur...
107:M 20 Nov 2024 05:57:12.193 * Sauvegarde du dernier instantané RDB avant de quitter.
2024-11-20 05:57:12.194 UTC [39] LOG : l'arrière-plan "logical replication launcher" (PID 54) s'est terminé avec le code de sortie 1
2024-11-20 05:57:12.194 UTC [49] LOG : arrêt en cours
107:M 20 Nov 2024 05:57:12.197 * DB sauvegardé sur disque
107:M 20 Nov 2024 05:57:12.197 # Redis est maintenant prêt à quitter, au revoir...
2024-11-20 05:57:12.227 UTC [39] LOG : le système de base de données est arrêté

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  if [ $(git rev-parse --is-shallow-repository) == "true" ]; then
      git remote set-branches --add origin main
      git remote set-branches origin tests-passed
      git fetch --depth 1 origin tests-passed
  else
      git fetch --tags --prune-tags --prune --force origin
  fi
' a échoué avec le retour #<Process::Status: pid 144 exit 128>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "hook"=>"code", "cmd"=>["sudo -H -E -u discourse git reset --hard", "sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\\n  set -o errexit\\n  if [ $(git rev-parse --is-shallow-repository) == \\\"true\\\" ]; then\\n      git remote set-branches --add origin main\\n      git remote set-branches origin $version\\n      git fetch --depth 1 origin $version\\n  else\\n      git fetch --tags --prune-tags --prune --force origin\\n  fi\\n'", "sudo -H -E -u discourse bash -c '\\n  set -o errexit\\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\\n      git pull\\n  else\\n      git -c advice.detachedHead=false checkout $version\\n  fi\\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \\\"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\\\"", "bash -c \\\"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\\\"\", \"bash -c \\\"mkdir -p           /shared/{uploads,backups}\\\"\", \"bash -c \\\"ln    -s           /shared/{uploads,backups} $home/public\\\"\", \"bash -c \\\"mkdir -p           /shared/tmp/{backups,restores}\\\"\", \"bash -c \\\"ln    -s           /shared/tmp/{backups,restores} $home/tmp\\\"\", \"chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp\", \"[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete\"]}\nbootstrap a échoué avec le code de sortie 128
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.

Désolé les gars, c’était un problème de proxy. J’ai dû configurer les proxys dans ~/.docker/config.json pour qu’ils soient injectés dans le conteneur, et ça a fonctionné …

Mon dieu, combien de temps ai-je perdu avec des problèmes de proxy ?? :stuck_out_tongue:

3 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.