Project

General

Profile

Actions

Bug #7867

open

Suppression d'un projet personnel puis fork d'un projet du même nom

Added by Ferrand Rémi about 10 years ago. Updated over 6 years ago.

Status:
Feedback
Priority:
Low
Assigned To:
-
Target version:
-
Start date:
08/19/2014
Due date:
% Done:

0%

Estimated time:

Description

Je viens de tomber sur un bug gitlab:

  • Mes étapes:
  • Création d'un projet "puppet-remctl" sous le groupe CC-IN2P3 Kerberos.
  • fork du repository "puppet-remctl" en tant que Remi Ferrand.
  • le fork échoue car un projet du même nom existe dans mon namespace.
  • Je supprime le projet "puppet-remctl" dans mon namespace
  • Le projet "puppet-remctl" est effectivement supprimé dans mon namespace.
  • Je retente un fork de 'puppet-remctl' du groupe CC-IN2P3 Kerberos
  • Je me prends une erreur "Fork transaction failed" en continue (cliquer sur le bouton "Retry Fork" ne change rien).

  • Fix trouvé:

  • Créer un projet "puppet-remctl" dans mon namespace

  • Supprimer immédiatement ce nouveau projet (pour refaire un clean de mon namespace, des fois qu'un DROP ou un DELETE aie échoué)

  • Recommencer le fork qui cette fois fonctionne.

Actions #1

Updated by Brétel Foudil about 10 years ago

  • Status changed from New to In progress

Pas réussi à reproduire:

  • création projet 'fbretel/cc-modele-de-couts'
  • je push du contenu vers ce répo
  • j'essaie de cloner 'cc-in2p3/cc-modele-de-couts' => erreur existing path
  • je détruis 'fbretel/cc-modele-de-couts'
  • je clone 'cc-in2p3/cc-modele-de-couts' sans attendre et sans problème

Ai-je loupé qq chose ?

Actions #2

Updated by Bussery Justin over 6 years ago

  • Status changed from In progress to Feedback

Je ne pense pas que le problème soit toujours d'actualité mais si c'est le cas, c'est dû à la gestion des background jobs qui font ce travail de nettoyage et qui n'auraient pas eu le temps de s'exécuter.

Actions #3

Updated by Guillon Benjamin over 6 years ago

Je confirme avoir observé ce phénomène également.

Les jobs qui sont mis en file sur sidekiq pour réaliser l'opération de clean du répo qui vient d'être supprimé peuvent mettre entre 2 et 5mn avant d'être exécutées.

Par conséquent, tout fork recréé immédiatement après la suppression, et ayant donc le même nom, sera supprimé par ces jobs lors de leur exécution si elle survient après.

Je ne pense pas que l'on puisse y faire grand chose ... :/

Actions

Also available in: Atom PDF