Intégration GIT

Nous allons d’ici quelque jours passer a un fonctionnement ou tous les developpeurs vont travailler sur leur environnement local et commiter le travail sur un repo Gitlab.

Je teste la mise en place et l’initialisation de l’environnement. Je me rend compte que ça va pas être aussi simple que je pensais à l’init.
L’idée globale :

Le repo git est déja initialisé avec notre module en mode EXPORT_MODULE_EXPLODED

L’idée serait qu’a l’initialisation, chaque développeur parte d’un module vide et vienne l’initialiser à partir du contenu de la branche develop de gitlab. Sauf qu’a priori ça ne fonctionne pas. J’ai bien reussi à pousser tous les commit sur le GIT du container mais les modification ne sont pas prises en comptes. Faut-il lancer un import ?

Autre chose, concernant le paramètrage simplicité, y’a-t-il possibilité d’avoir une fonctionnalité d’auto-commit qui se déclenche à chaque modification d’objet pour conserver un historique complet des modifications ? merci !

Pour installer un module il faut toujours passer par l’action “import module”, qui, selon ce qui est fourni (un fichier XML, ZIP, une URL HTTP, une URI Git) utilisera ce qu’il faut.

Perso je gère mes modules sur Github (en protocole SSH et avec des clés SSH) avec des settings du genre:

{
	"type": "git",
	"origin": {
		"uri": "git@github.com:dazoulay-simplicite/module-xxx.git"
	}
}

ce qui donne au niveau de la UI les boutons suivants:

Attention il y a un bug connu sur la prise en compte des settings Git, parfois il faut ré-enregistrer le module en ayant fait une modif “neutre” dans les settings (genre ajouter un espace ou une ligne vide en plus) pour que ceux-ci soient pris en compte. Autre contrainte si vous fonctionnez avec une clé SSH un changement sur celle-ci n’est prise en compte qu’après un arret/relance Tomcat

Et non il n’y a pas de mécanisme d’“auto-commit” sur toute action de paramétrage ce serait trop lourd (un commit est fondamentalement un export module). Commiter reste une action volontaire d’un développeur qui dit “j’ai fini de traiter ci ou ça”, c’est pas un mécanisme technique de piste d’audit, pour ça il y a le redo log que vous pouvez, si besoin, être activé pour tous les objets y compris les objets systèmes.

D’accord. Est ce qu’on peut utiliser nos clés .ssh windows via un montage de volume ou il y a une autre manière de procéder ?

Dans le contexte Docker, il faut copier dans une image custom (ou monter dans le container) votre clé SSH à son emplacement “par défaut” i.e. /root/.ssh/id_rsa (attention aux droits du le répertoire .ssh (= 500 ou 700) et sur le fichier id_rsa (400 ou 600)).

On a pas prévu de mécanisme de plus haut niveau (genre la clé dans un param système ou à emplacement custom indiqué par un param système) pour le moment mais ça peut s’étudier si besoin.

Je précise que je ne l’ai jamais fait personnellement dans ce contexte Docker mais je ne vois pas de raison pour que ça ne marche pas. Je testerai à l’occasion.

C’est surtout que dans le dockerfile c’est plus lourd à mettre en place ( 1 dockerfile par developpeur).

J’ai essayé de monter via un volume mais ça n’a pas l’air de fonctionner, bien que les droits correspondent bien.

OK je testerai ça demain si possible

Dans mon cas ça marche mais je pense que c’est parce qu’il y a un known_hosts qui contient déjà github.com. Peut être faut il donc aussi monter aussi le known_hosts local

C’est un problème de droit lié au montage du volume depuis windows je crois. Je n’arrive pas à faire de git clone depuis le terminal du container.

Ça fonctionne bien quand je génère la paire de clé sur le container directement et que je fait un git clone manuel. J’essaie de trouver un contournement pour prendre la clé du poste.

On pourrait avoir une clé dans l’image en dur et chacun ajoute la clé publique dans son profil github mais de fait les commits deviendraient anonyme je pense…

Oui c’est pas idéal d’avoir une clé “commune”.

J’ai parlé des droits sur le répertoire .ssh et sur les fichiers de ce répertoire (ainsi que sur le répertoire parent mais là vu que c’est /root ça doit être bon) car c’est un des truc que vérifie SSH. Il est impératif que seul le user (ici root) ait les droits.

Voilà ce que j’ai dans un cas qui marche (hors Docker):

ls -alF .ssh
total 24
drwx------  2 xxx simplicite 4096 Feb  9 17:24 ./
drwxr-x--- 11 xxx simplicite 4096 Feb  9 17:21 ../
-rw-------  1 xxx simplicite  810 Jan 18 10:56 authorized_keys
-rw-------  1 xxx simplicite 1675 Jun 16  2020 id_rsa
-rw-r--r--  1 xxx simplicite  404 Jun 16  2020 id_rsa.pub
-rw-r--r--  1 xxx simplicite  394 Feb  9 17:24 known_hosts

PS:

Cf. Docker Tip #56: Volume Mounting SSH Keys into a Docker Container — Nick Janetakis
Je vais ajouter la copie et les chmods indiqués sur /root/.ssh dans l’entrypoint des images, on verra si ça résoud le pb de droits windows… (du coup il faudra monter le .ssh local ailleurs genre dans /usr/local/tomcat)

Ça me semble être une bonne solution. En attendant de tester avec la nouvelle image, j’ai testé l’import du module via git mais j’ai une erreur de format

2021-02-09 16:44:24,003 ERROR [com.simplicite.util.engine.Interface] SIMPLICITE|http://7e2bf208a12b:8080||ERROR|designer|com.simplicite.util.engine.Interface|importModule||Event: Module: name: Data file: /usr/local/tomcat/webapps/ROOT/WEB-INF/tmp/importmodule-name-1612889063439-kLwaC4c2D6kuroLGqxmizvFCA12J7zyC/configuration/Module/name.json is not of the right format

{
  "name":"Module",
  "action":"upsert",
  "data":[{
    "mdl_name":"name",
    "mdl_version":"0.3.0",
    "mdl_prefix":"nam",
    "mdl_url":"",
    "mdl_lastupd":"2020-10-06 09:58:10",
    "mdl_comment":"xx"
    }]
}

Mmm OK ça c’est un autre sujet, je dépile dans l’ordre sinon je vais rater des choses

Pour les clés SSH c’est expliqué là: Simplicité® documentation/90-operation/docker

Ce sera applicable aux images qui seront poussées cette nuit.

Testé ce jour, ça m’a l’air OK

version: "3"
services:
  simplicite:
    image: simplicite/platform:5
    environment:
      SSH_KNOWN_HOSTS: "github.com"
    ports:
      - 127.0.0.1:8443:8443
    volumes:
      - ./ssh:/usr/local/tomcat/.ssh:ro

J’ai pu importer un module d’un répo privé sur GitHub avec des settings du genre:

{
	"type": "git",
	"origin": {
		"uri": "git@github.com:dazoulay-simplicite/xxx.git"
	}
}

Dans mon répertoire ssh j’ai juste une clé privée (connue sur GitHub) dans id_rsa.

PS: testé sur une machine hôte Linux et Windows 10

1 Like

Je confirme, plus de problème d’authentification de cette manière !

Par contre j’ai ce problème de format json innaproprié :

2021-02-11 09:01:31,517 ERROR [com.simplicite.util.engine.Interface] SIMPLICITE|http://d0dfd591f332:8080||ERROR|designer|com.simplicite.util.engine.Interface|importModule||Event: Module: name: Data file: /usr/local/tomcat/webapps/ROOT/WEB-INF/tmp/importmodule-name-1613034090496-7al3r24jyE68a493MYAPl9SxUtego8GZ/configuration/Module/name.json is not of the right format

J’ai testé avec notre repo actuell toujours au format xml et le nouveau qui contient le module au format JSON mais même erreur.

com.simplicite.util.exceptions.ImportException: Data file: /usr/local/tomcat/webapps/ROOT/WEB-INF/tmp/importmodule-name-1613034266694-AY72817nsOvHXw4e4IUSiwR0qNdsJLaA/configuration/Module/name.json is not of the right format
at com.simplicite.util.engine.Interface.importModule(Interface.java:1448)
at com.simplicite.util.IntegrationDirect.importModule(IntegrationDirect.java:409)
at com.simplicite.util.Integration.importModule(Integration.java:805)
at com.simplicite.util.Integration.importModuleZIP(Integration.java:783)
at com.simplicite.util.tools.GitTool.importModule(GitTool.java:1392)
at com.simplicite.objects.System.Module.importModule(Module.java:949)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:4299)
at com.simplicite.util.ObjectDirect.invokeAction(ObjectDirect.java:623)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2110)
at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:1088)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2078)
at com.simplicite.webapp.tools.JSONServletTool.action(JSONServletTool.java:1809)
at com.simplicite.webapp.ObjectJson.action(ObjectJson.java:677)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:616)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:69)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:139)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:86)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.simplicite.webapp.filters.HTTPHeadersFilter.doFilter(HTTPHeadersFilter.java:39)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)
at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:192)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:346)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:887)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1684)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:832)

Le contenu du repertoire /usr/local/tomcat/webapps/ROOT/WEB-INF/tmp/ est supprimé après chaque tentative infructueuse ? Ce repertoire sur le container est vide

Je suis en train de regarder ce pb.

PS: Je ne sais pas trop ce qu’il en est pour ce répertoire tmp dans ce ca là mais de manière générale tout ce qui se trouve dans un espace disque temporaire est purgé à la fin du processus qui l’utilise (que ça soit un succès ou une erreur), c’est plutôt s’il reste quelque chose qu’il y a un pb…

OK vu et corrigé.

Le cas d’import depuis un repo Git externe en mode “exploded” était un cas particulier de l’import ZIP pas bien géré. Désolé.

Merci, quand est ce que ça sera dispo sur la 5.0 latest ?

Ce sera packagé ce soir (= version 5.0.17)

Ca fonctionne presque nickel, mais l’import plante pour une raison que je n’arrive pas à déchiffrer :

2021-02-12 10:23:12,617 INFO  [] Start import object Resource:
2021-02-12 10:23:12,617 INFO  []   Found field res_type = [CSS]
2021-02-12 10:23:12,617 INFO  []   Found field res_cached = [0]
2021-02-12 10:23:12,617 INFO  []   Found field res_object = Object[Disposition:responsive]
2021-02-12 10:23:12,617 INFO  []   Found field row_module_id.mdl_name = [name]
2021-02-12 10:23:12,617 INFO  []   Found field res_lang = [FRA]
2021-02-12 10:23:12,617 INFO  []   Found field res_file = path 52307
2021-02-12 10:23:12,617 INFO  []   Found field res_file_compiled = []
2021-02-12 10:23:12,617 INFO  []   Found field res_code = [STYLES]
2021-02-12 10:23:12,617 INFO  []   Found field res_image = []
2021-02-12 10:23:12,618 INFO  []   Found internal key row_id = 271
2021-02-12 10:23:12,619 INFO  []   Action: UPDATE
2021-02-12 10:23:12,622 ERROR []   Import file error: 52307 in res_file, NO_FILE_FORMAT
2021-02-12 10:23:12,622 ERROR [] Error SAVE: import files

Des pistes ?