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:
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.
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.
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…
J’ai parlé des droits sur le répertoire .sshet 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
Ç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
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
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…
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