Bonjour,
Est-il possible de paramétrer la sauvegarde GIT des modules pour utiliser un GIT externe?
Oui les modules Simplicité exposés sous forme de repo Git sont clonable comme tout repo Git
Merci pour votre réponse.
Est-il possible de sauvegarder directement sur un git externe ou faut-il obligatoirement faire une sauvegarde git locale + clonage vers git externe?
Je ne comprends pas forcément votre question mais il n’y a rien de spécifique à Simplicité concernant Git.
Je souhaite commit + push sur un git externe au lieu de le faire sur le git local
Avec Git un commit est toujours local et on peut pousser sur un ou plusieurs remote
Dans le cas des repo des modules (qui sont donc localement sur le serveur) il est possible de configurer des remotes dans les settings du module et de pousser dessus sélectivement (je ne sais pas si c’est dispo en 3.2)
Une autre approche est de cloner le repo à l’extérieur et de configurer sur ce repo cloné des remotes en plus de l’origin.
Etc.
Comme toujousr avec Git de nombreux patterns sont envisageable.
j’ai mis en paramètre de mon module
{
“type”: “git”,
“origin”: { “uri”: “https://github.com/roprasp/moduleresa.git” }
}
et quand je clique sur “repository git”
L’origin n’est pas celle que j’ai configurée.
Si vous changez les settings après avoir créé le repo local du module je pense que ça ne marchera pas. Il aurait fallu le créer comme ça initialement (ça aurait créé le repo par clonage du remote origin)
Je vais faire qques tests et voir si on pourrait prendre en compte les changements de settings. Je vous tiens au courant.
J’ai fait le test suivant (en 4.0 à jour):
- Je créé un repo Git vide sur GitHub (ici
simplicitesoftware/mymodule) - Je créé un module
MyModulesur Simplicité avec les settings suivants:
{
"type": "git",
"origin": {
"uri": "https://github.com/simplicitesoftware/mymodule.git",
"username": "<un user GitHub qui a les droits d'écriture sur le repo>",
"password": "<le password du user ci dessus>"
}
}
- Je fais qques paramétrages dans le module
MyModule - Je clique sur Repository Git au niveau du module, je commite et je push sur le remote
origin:
- Au niveau du repo GitHub je vois alors bien ce que j’ai commité+pushé:
PS: Dans votre cas il manque les settings username et password (requis pour pouvoir pousser sur GitHub, optionnels pour puller)
Si la modif de settings ne suffit pas, il vous faudra:
- exporter en XML votre module et télécharger le ficher (au cas où)
- Supprimer le repo Git de votre module et le recréer avec les settings qui vont bien + importer le module (c’est l’import qui clone le repo distant), l’import d’un module vide affichera sans doute une erreur mais c’est pas grave
- Recharger le paramétrage par import XML si jamais votre paramétrage a disparu suite à l’opération ci-dessus
- Commiter et pusher
NB: Attention tout de même, un repo GitHub est public par défaut (les repos privés sont payants), c’est donc pas forcément le meilleur service de repo Git si vous voulez gérer des repos privés…
Je n’ai plus les boutons push / pull / fetch sur mon instance bytel, ni sur formation2.
les 2 applis sont sur la version :
Simplicité® version 4.0.P13b, built on 2018-03-20 23:29 (revision 11369ccc20c30b41c0712213efa1ccdb781149b2)
edit : formation2 est sur la version 4.0.P13b
mais bytel est sur la version
Simplicité® version 4.0.P12, built on 2018-03-12 16:45 (revision 4fd20b7b8f9fbd32a2a3bc006d0a76d736a883a3)
Sur quel serveur est cette instance “bytel” ? Elle est visiblement calée sur la branche release de Simplicité (la dernière révision poussée sur cette branche est bien la 4fd20b7b8f9fbd32a2a3bc006d0a76d736a883a3)
“formation2” est sur le serveur de demo/formation et est bien en autoupdate, elle est donc bien à jour sur la branche master (revision 11369ccc20c30b41c0712213efa1ccdb781149b2)
Indépendamment de la révision (car il n’y a pas eu de travaux récents sur cette partie) la presence des boutons push/pull/fetch est conditonnée au fait que le repo du module ait un ou plusieurs remotes (donc, par exemple, que ce soit un clone d’un repo distant, cf. mon exemple).
bytel est sur le serveur partenor.simplicite.io
Il y avait une erreur de syntaxe dans mes paramètres, j’ai corrigé et cela fonctionne correctement, merci.
Je ne vois pas d’instance bytel sur partenor (ça doit être un autre nom…)
En tout cas je confirme que ce serveur partenor est calé sur la branche release 4.0, donc même si votre instance est en autoupdate c’est normal qu’elle ne soit pas sur la même révision que l’instance sur le serveur demo qui, lui, est calé sur la branche master (i.e. le daily build)
Bonsoir,
nous avons aussi un problème non résolu de sauvegarde de nos modules sur un git externe et les éléments de solution exposés dans ce post ne fonctionnement pas dans notre cas…
Quelque soit l’ordre des opérations (reconfiguration d’un module existant ou configuration d’un nouveau module “à blanc”, nous n’avons à aucun moment la possibilité d’interagir avec le remote configuré (jamais de boutons “push/pull” ni de combo “origin”) suite au click sur le bouton “Git repository”.
Nous avons au moins deux éléments de contexte qui diffèrent :
- nous utilisons GitLab (et pas GitHub)
- nous devons nous baser sur un repo GitLab unique (mis en ligne pour l’ensemble du projet) dans lequel doivent être rassemblés nos modules (et pas un repo par module)
J’ai essayé d’utiliser le paramètre “branch” pour distinguer les espaces de commit des différents modules mais c’est peut-être inutile…
Voici le paramétrage utilisé dans mes tests:
{
“type”: “git”,
“origin”: {
“uri”: “https://gitlab.intra.renault.fr/irn-68521/bca.git”,
“username”: “{user git avec les autorisations en commit}”,
“password”: “{password}”,
“branch”: “{le nom d’un module}”
}
}
David, je sais que Marouane et toi avez plusieurs fois échangé sur notre problématique et je n’ai pas connaissance de tous vos échanges… Vous avez peut-être déjà traité ce point (auquel cas, n’hésite pas à me renvoyer vers Marouane sur qui je sauterai dès son retour de congés ;))
NB: Simplicité® version 4.0.P19, built on 2018-06-09 15:49 (revision 8d8a4bc8eb25a784affad4e9c95ba2fe65591711) for tomcat 8, encoding UTF-8 (system encoding UTF-8)
Server: Apache Tomcat/8.5.31 of type WEB run by user root, Database MySQL
JVM: 1.8.0_171 Oracle Corporation OpenJDK 64-Bit Server VM 25.171-b10, OS: Linux amd64 3.10.0-693.17.1.el7.x86_64
Le principe fondamental des mécanismes natifs Git offerts par Simplicité est de gérer un repo Git par module.
Il est sans doute possible de gérer des repo Git “nested” dans un “super” repo, mais c’est hors scope de Simplicité (et de ce forum). Nous n’avons pas vraiment les compétences Git requises pour vous assister sur cette stratégie Git qui de toute façon n’a rien de specifique à Simplicité.
En tout état de cause, si les mécanismes Git natifs de Simplicité ne sont pas adaptés à la stratégie Git que vous voulez mettre en place vous devez très bien procéder procéder autrement: Par exemple rien ne vous empêche d’exporter vos N modules en ZIP puis de les dézipper dans votre repo Git unique (selon une arborescence ad-hoc) une telle logique est très facilement scriptable.
Bonjour David,
merci beaucoup pour ton retour.
C’est donc bien notre repo “global” qui pose problème.
Je fais le point avec Marouane à son retour pour déterminer ce que nous ferons.
Cdlt
Il y a une infinité de stratégies possibles quand on se sert de Git. Il faut donc:
- choisir votre stratégie Git
- voir quel(s) mécanisme(s) Simplicité doivent être utilisé dans cette stratégie
Parfois la réponse au point 2 c’est d’utiliser directement les repo Git gérés par Simplicité pour ses modules, parfois non.
Par exemple pour les modules que nous rendons publics sur GitHub (ex: https://github.com/simplicitesoftware/module-pizzeria) et/ou sur GitLab (ex: https://gitlab.com/simplicitesoftware/module-pizzeria) ces repos gérés sur GitHub et GitLab ne sont que de simples remotes additionnels associés aux repos des modules gérés dans Simplicité.
Dans d’autres cas nous exportons simplement N modules en XML (ou, mieux, en ZIP dézippés) dans un repo Git totalement externe à Simplicité (cela permet alors de gérer l’historique des N modules versionnés dans un seul repo Git, ce qui n’empeche aucunement de gérer l’historique individuel de chaque module dans son repo Git géré par Simplicité)
Etc.
Bonjour David,
c’est très clair.
Merci beaucoup.
Marouane a fait en sorte que nous puissions gérer directement des “sous-projets” Git pour chaque module (chaque module a son URI Git). Il teste actuellement cette nouvelle configuration. Si tout fonctionne comme nous le souhaitons, nous devrions pouvoir paramétrer chaque module sur son propre remote géré par Simplicité (commit/push depuis l’instance de DEV et fetch/pull depuis les instances de RE7/OPE).
Bonjour,
J’essaie d’effectuer les opérations décrites ci-dessus mais l’interface permettant de pousser ma configuration sur un git externe n’apparait pas dans la partie “Git repository” pour mon repo sur un gitlab déployé sur internet (j’ai bien vérifié que mon serveur dockerisé peut s’y connecter, j’ai mis l’url et les credentials dans le champ settings).
Quel type de customisation ou d’opérations (clean cache ?) permettent d’obtenir l’IHM pour pousser sur un remote SVP ?
J’ai testé la manipulation sur le tag “beta” et la tag “latest” de la version dockerisé de Simplicite.
Quand j’utlise l’url du git de demo https://github.com/simplicitesoftware/module-demo dans le champ setting sur un nouveau module, le champ pour pousser sur le git remote apparait après quelques minutes et customisation (sans que je comprenne vraiment ce qui a permis de l’afficher)
Merci pour votre aide