Bonjour,
Régulièrement lorsqu’on clone un projet, il y’a un conflit entre le .gitignore généré par simplicité et le .gitignore de notre repo.
Le workarround le plus “simple” qu’on ait trouvé jusqu’à présent c’est de supprimer le .gitignore dans le container avant de faire l’import depuis git. Y’a-t-il une autre manière plus simple d’éviter cette manipulation à chaque fois qu’on part d’un nouveau conteneur ?
Sur une version 5.x à jour (l’évolution n’est pas très récente) le .gitignore est généré lors du 1er commit du module, ensuite il n’est plus regénéré donc il ne devrait jamais induire de conflits, même si vous le modifiez manuellement.
Quelle version utilisez vous ?
PS: j’ai vérifié l’évolution en question date de la révision 5.0.20 (16 février 2021) Simplicité® 5/releasenote/releasenote-5.0
On utilise 5.0.30 mais l’évolution que vous décrivez ne semble pas fonctionner dans notre cas d’usage.
Je set le nom de la branche dans le settings de mon module et lors de l’import il bloque immédiatement sur le .gitignore. A ce moment là, dans le répertoire git il n’y a que le .git et le .gitignore.
OK on est dans le cas particulier d’un changement de branche.
Je vais regarder ce cas de plus près et je reviens vers vous.
PS: En tout état de cause votre répertoire git devrait être monté comme un volume persistant de votre container, cf. les exemples dans docker/examples/docker-compose at master · simplicitesoftware/docker · GitHub il y a systématiquement un volume pour ce répertoire git
Dans la révision 5.0.36, nous avons changé le moment où le .gitignore est généré. Dites moi si cela résout votre pb dans votre cas d’usage.
Super, merci on vous tiendra au courant, on devrait rapidement le savoir déployant la nouvelle version de l’image vierge.
A priori c’est bon. Nous vous reconfirmerons sur le long terme si l’erreur est définitivement erradiquée.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.