Onedev : une alternative légère à GitLab

Posté par . Édité par Benoît Sibaud, Davy Defaud et Xavier Teyssier . Modéré par ZeroHeure. Licence CC By‐SA.
Étiquettes :
35
4
fév.
2020
Administration système

Onedev est une application web tout‐en‐un, simple et puissante pour héberger vos dépôts Git avec gestion des bogues, des fusions et construction des binaires. Dans son esprit de simplicité, le Readme du dépôt Onedev présente le fonctionnement par des copies d’écran animées. Onedev, qui porte bien son nom, est quasiment l’œuvre d’une seule personne, Robin Shine, qui le développe sporadiquement depuis 2012 (en Java). Bien sûr, le projet est auto‐hébergé. La version 3.0.5 de Onedev vient de sortir. Le projet est sous licence MIT.

N. D. M. : il existe déjà diverses alternatives (sur toutes ou partie des fonctionnalités) libres à GitLab comme Gogs, Gitea, Phabricator, Trac, Tuleap, etc.

Aller plus loin

  • # Complet

    Posté par (site web personnel, Mastodon) . Évalué à 4.

    A la lecture de l'article je m'attendais à une solution type Gitea mais Onedev semble proposer un très grand nombre de fonctionnalités ! Je note ...

    🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr

  • # Sourcehut

    Posté par . Évalué à 4. Dernière modification le 04 février 2020 à 17:12.

    Le problème avec tous ces outils gitlab, github, gitea, etc.. c'est qu'excepté le code sous git tout est centralisé sur un serveur (issues, pull/merge requests, ...). Une fois que tu démarres sur une plateforme, bon courage pour en changer. Et le gros intérêt de git c'est quand même la décentralisation, sinon autant utiliser mercurial et cie.

    A ma connaissance seul https://sourcehut.org/ essaye d'avoir une réflexion derrière cette problématique, en utilisant un outil simple et modulaire qui a fait ses preuves (i.e. le courriel).

    C'est encore en alpha, leur système de build est vraiment chouette (tu peux ssh sur les builds échoués), et vu que c'est modulaire vous pouvez déployer juste ce que vous voulez chez vous.

    • [^] # Re: Sourcehut

      Posté par . Évalué à 4. Dernière modification le 04 février 2020 à 17:38.

      Et le gros intérêt de git c'est quand même la décentralisation, sinon autant utiliser mercurial

      LOL

      https://sourcehut.org/

      First-class Mercurial support also available

      LOL++

      • [^] # Re: Sourcehut

        Posté par . Évalué à 3.

        s/hg/cvs/ :) mon point était que c'est un peu ridicule toute ces plateformes qui utilisent git pour centraliser issues/pr par la suite.

    • [^] # Re: Sourcehut

      Posté par . Évalué à 4.

      J'ai exactement ce problème !

      J'utilise redmine depuis plus de 12 ans uniquement sur la partie support : gestion tickets (bug, évolution), des docs supplémentaires mais sans intégration zip. J'ai un dépot sur ma machine de dév et je zip régulièrement le projet que j'attache en PJ.

      J'ai envie de changer car j'avoue que le mode d'intégration et le côté sexy sont très attirants, sans parler de la possibilité de revue de code qui est simplifié grâce à l'intégration de git... Ce qui me rebute c'est de perdre mon historique de ticket. En même temps, les anciens tickets on s'en fou et j'ai déjà une release note qui accompagne chacune de mes applis en prod (? > About).

      L'idéal serait une solution à base de tickets directement gérés dans git. Et chacun se fait l'interface qu'il veut (web, mobile, pc...).

      Vos avis ?

    • [^] # Re: Sourcehut

      Posté par (site web personnel) . Évalué à 7.

      Pour information : Mercurial est un DVCS autant distribué que Git.

      AI is a mental disorder

    • [^] # Re: Sourcehut

      Posté par . Évalué à 6.

      Une fois que tu démarres sur une plateforme, bon courage pour en changer. Et le gros intérêt de git c'est quand même la décentralisation, sinon autant utiliser mercurial et cie.

      C’est compliqué (très compliqué), mais pas impossible.

      Les sources/tickets/etc. de ./play.it étaient à l’origine gérés sur GitHub, puis ont migré vers Framagit. Aujourd’hui, tout ça se trouve sur une forge GitLab auto-hébergée.

      Aucun ticket, aucune discussion n’a été perdue. Mais bien sûr les migrations ont pris du temps et de l’énergie, et les tickets bouclés ont été archivés sur leur plateforme d’origine plutôt que copiés vers les nouvelles plateformes.

    • [^] # Re: Sourcehut

      Posté par . Évalué à 1.

      Si tu peux contenter de l'interface (très) minimaliste de Fossil, tout est décentralisé.

      Mais du coup, il a moins de fonctionnalités que les outils centralisés. En gros : Source, bugs et wiki.

  • # 1er lancement foireux

    Posté par . Évalué à 1.

    pas de bol

    $ server.bat start
    Stdin CreateNamedPipe failed (231): Toutes les instances des canaux de communication sont occupées. (0xe7)

    • [^] # Re: 1er lancement foireux

      Posté par . Évalué à 2.

      sous windows, problème de droits visiblement...

      • [^] # Re: 1er lancement foireux

        Posté par . Évalué à 6.

        donc faut être admin puisque :
        $ server.bat install
        $ server.bat start

        En dehors de ça, l'interface est très sympa et il y a vraiment plein de fonctionnalités intéressantes. J'ai rapidement retrouvé une config encore mieux que celle de redmine.

        Ce qui est vraiment frappant c'est la facilité d'install et de déploiement, un bundle complet et prêt à l'emploi. RESPECT !

  • # Hmm

    Posté par (site web personnel) . Évalué à 3.

    Onedev : une alternative légère à GitLab

    Au vu des copies d'écran et sachant que c'est du Java, j'ai quand même du mal à voir comment on peut parler de légèreté :p

    C'est vraiment le nombre de fonctionnalités qui me fait dire que c'est un GitHub like mais pas un truc léger.

    • [^] # Re: Hmm

      Posté par . Évalué à 1.

      À vrai dire je le pensais aussi, mais c'est l'auteur, modeste sans doute, qui le qualifie d''alternative légère.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Hmm

      Posté par (site web personnel) . Évalué à -1. Dernière modification le 05 février 2020 à 10:55.

      En effet j'ai pensé la même chose quand j'ai vu que c'était en Java. Je me souviens encore de mon pauvre serveur quand celui ci tournait Tomcat et Red5. Ma pauvre RAM et mon CPU en avaient bien souffert.

      Le Java a eu son heure de gloire avec le web dymanique, mais depuis il existe tellement d'alternatives légères en framework que je comprends pas qu'il ne soit toujours pas mort.

      AI is a mental disorder

      • [^] # Re: Hmm

        Posté par . Évalué à 3. Dernière modification le 05 février 2020 à 12:04.

        Java ça se fait très bien sans Tomcat ou autre serveur d'applications, hein. Même pour du backend RESTful.

        (Bon, par contre, effectivement, quand je vois des archis micro-services où chaque "micro" service lance un Tomcat, je pleure ou rigole selon mon humeur)

    • [^] # Re: Hmm

      Posté par (site web personnel) . Évalué à 10. Dernière modification le 05 février 2020 à 11:25.

      Pourquoi Java serait plus lourd que Javascript, Python, Ruby, PHP ou n'importe quelle technologie répandue côté serveur ? C'est un langage qui a une excellente VM (JIT efficace, très bon garbage collector). C'est probablement plus rapide que Python ou Javascript, qui sont extrêmement dynamiques sur tous les tableaux.

      Bien sûr, l'écosystème Java est rapidement lourd (perso je ne suis pas fan du tout), mais si on veut programmer un truc léger en Java, j'imagine qu'on peut le faire... en tout cas au moins autant qu'en Python ou en Javascript.

      Il y aurait probablement moyen de faire plus léger en C, C++, Rust, D ou autre langage compilé d'une rapidité et d'une efficacité en mémoire comparable à celles du C, mais ce n'est pas très répandu.

      Et je dis ça en tant que quelqu'un qui n'aime pas particulièrement Java et qui aime plutôt bien Python et Javascript.

      Côté client en tout cas, OneDev semble répondre vite, et a l'air de fonctionner plutôt bien sans Javascript pour les opérations qui n'en ont pas vraiment besoin. Tout ça, contrairement à GitLab où on voit pas mal de logos de chargement un peu partout.

      • [^] # Re: Hmm

        Posté par (site web personnel) . Évalué à -3.

        Sans doute parce que c'est quand même plutôt le cas. Pour toutes les applications Java que j'ai hébergé côté serveur ma RAM et mon CPU étaient en galère (red5, tomcat, jenkins).

        En local, tuxguitar n'est pas ultra léger non plus mais il reste correct.

        Par contre, le développement Android, je ne préfère même pas en parler.

        AI is a mental disorder

        • [^] # Re: Hmm

          Posté par (site web personnel) . Évalué à 8. Dernière modification le 05 février 2020 à 14:39.

          Yes, mais c'est aussi vrai avec Javascript. Etherpad, par exemple, consomme un max de mémoire même sans rien faire et de CPU, côté serveur. Je suspecte que le langage n'importe pas autant que les choix de conception cela dit dans ce cas. J'ai lu que gitlab était très gourmand en ressources aussi (Ruby).

          Pour moi, Android est justement un exemple de plateforme où on peut trouver des applications Java très légères.

          Le développement d'applications Android c'est une autre histoire. C'est beaucoup trop lourd et pénible par rapport à ce que ça devrait être. Et alors si en plus l'application utilise Javascript et npm, là tu as tout gagné.

          Mais je reconnais qu'en Java, on a très vite la mauvaise habitude de mettre des classes et d'empiler des abstractions sur des abstractions à tout bout de champs.

        • [^] # Re: Hmm

          Posté par . Évalué à 2.

          Pour Puppet c’est pareil :

          • puppet-master était écris en ruby et consommait ce dont il avait besoin ;
          • puppetserver est écrit en clojure/ruby et tourne sur une JVM qui demande plusieurs Go de RAM dès le démarrage.

          C’est pas juste pour dire que c’était mieux avant (sur tout un tas de point, c’est mieux maintenant), mais le passage à la JVM a clairement fait augmenter le dimensionnement des VM.

          • [^] # Re: Hmm

            Posté par . Évalué à 5.

            Là c'est pas une question de java ou de ruby, mais de jruby qui est une mauvaise idée. Elastic a réécri logstash de jruby à java pour ça.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Hmm

          Posté par . Évalué à 4.

          Quel est le rapport entre java et android ? Le langage se ressemble ? Il utilise le bytecode java dans l'une de ses étapes de build ?

          Android est un écosystème à part entière. Il a peut-être des ponts avec java, mais c'est comme confondre c et c++.

          Quant au reste du troll, je te le laisse. On est pas vendredi. Tu lâche un c'est lourd sans la moindre comparaison, expliquer ce que c'est que lourd, chercher comparer les langages eux même. Les bench entre le très aimé python et java pourrais être intéressants pour alimenter la discussion. Mais ça n'est pas l'objectif. Continuer à balancer des poncifs en mode cargo cult (java c'est mal, javascript c'est mal, python c'est bien), c'est devenu une habitude par ici. Ça a remplacé les discussions techniques. Dommage.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Hmm

            Posté par (Mastodon) . Évalué à 3.

            J'utilise davmail au taf pour lire les mails corporate en exchange avec des clients mails utilisables genre pas outlook.
            C'est une passerelle, assez bien foutue, ça marche au poil pas de soucis, on lis ses mails comme si c'était de l'IMAP, youpi.

            C'est du java, et la RAM de ce petit bidule planqué dans la barre des tâche grimpe, et grimpe et grimpe, à plusieurs Go.
            Faut juste le relancer de temps en temps pour pas tout bloater.

            Alors :
            - c'est un exemple, ne généralisons pas ;
            - ça ne veut pas dire qu'il est lent ou poussif, il fonctionne plutôt bien, et je ne dis certainement pas que le même en python (par exemple) serait plus rapide ;
            - il existe des alternatives, genre plugin à thunderbird pour faire de l'exchange en direct ;
            - et je suis probablement suffisamment une brelle en java pour ne pas savoir comme paramétrer le bidule pour que la JVM ne s'auto-bloate pas.

            Mais bigre, si j'avais juste quelques outils dans ce goût là, j'aurais déjà développé un petit script, et réglé ma crontab, pour les relancer tous proprement, alternativement, genre toutes les heures !

            Alors que bon, mon emacs lancé depuis huit mois (par exemple), il fait pas tout péter comme ça.

            Ouais, Java ça peut être bien lourd, voire lourdingue.

            Pour le java et Android, ça fait un moment que Dalvik n'est plus l'environnement d'exécution par défaut (depuis Android 5), trop lourd justement, les applis sans Dalvik pompent environ 25% de batterie en moins. Mais ce n'est qu'une JVM, spécifique, et pas développée par Oracle, qui - donc - n'engage pas Java en entier, voire pas du tout.
            Uniquement le concept de machine virtuelle pour faire des applis natives...

            Yth.

          • [^] # Re: Hmm

            Posté par . Évalué à 3.

            Il y a eu assez de discussions sur le procès Oracle/Google à propos d'Android et Java. Oui, Android a repris (presque ?) toute l'API de Java, donc oui, le langage se ressemble.

            Même si la plupart du code C est à peu près valable en C++, ce dernier introduit suffisamment d'interfaces et de concepts nouveaux (par rapport à C) pour qu'on ne considère pas que ce soit le même langage.

            • [^] # Re: Hmm

              Posté par . Évalué à 3.

              C'est presque plus proche d'un fork de l'API. Android supporte l'API de java 7 et une partie de java 8. La comparaison n'est bien sûr pas identique, mais clairement ce sont 2 choses vraiment différentes. Les langages évoluent différemment, le runtime est très différent, l'écosystème est assez différent. Il y a un objectif de garder une certains compatibilité, mais quand on voit les release de guava par exemple on vois bien qu'il y a des différences.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Hmm

            Posté par (site web personnel) . Évalué à 5. Dernière modification le 06 février 2020 à 12:57.

            Quel est le rapport entre java et android ? Le langage se ressemble ? Il utilise le bytecode java dans l'une de ses étapes de build ?

            Android est un écosystème à part entière. Il a peut-être des ponts avec java, mais c'est comme confondre c et c++.

            Hein ?

            Java, c'est le langage privilégié pour développer des applications sous Android (avec Kotlin). Android a sa propre VM et n'utilise pas OpenJDK, mais je ne vois pas la différence niveau langage. Je ne comprends pas du tout le parallèle avec la comparaison C et C++.

            Bien sûr, une grosse partie d'Android est écrite en C et en C++, peut-être as-tu compris cela quand on parlait de développement Android ? En tout cas, pendant la compilation d'Android, beaucoup de code java est compilé.

            Après trois quarts d'heure de récupération des sources de LineageOS 17.1 (Android 10) et une heure trois quart de comptage de lignes de code (cloc), voici les résultats :

            875940 text files.
679492 unique files. 
521912 files ignored.
24 errors:
Line count, exceeded timeout: ./cts/tests/tests/ndef/src/android/ndef/cts/NdefTest.java
Line count, exceeded timeout: ./external/grpc-grpc/tools/doxygen/Doxyfile.c++
Line count, exceeded timeout: ./external/javaparser/javaparser-symbol-solver-testing/src/test/test_sourcecode/javaparser_new_src/javaparser-core/com/github/javaparser/ast/visitor/DumpVisitor.java
Line count, exceeded timeout: ./external/javaparser/javaparser-symbol-solver-testing/src/test/test_sourcecode/javaparser_src/proper_source/com/github/javaparser/ast/visitor/DumpVisitor.java
Line count, exceeded timeout: ./external/javaparser/javaparser-testing/src/test/test_sourcecode/com/github/javaparser/printer/PrettyPrintVisitor.java
Line count, exceeded timeout: ./external/libchrome/base/metrics/field_trial_unittest.cc
Line count, exceeded timeout: ./external/llvm/lib/MC/MCAsmStreamer.cpp
Line count, exceeded timeout: ./external/perfetto/ui/src/frontend/record_page.ts
Line count, exceeded timeout: ./external/swiftshader/third_party/llvm-7.0/llvm/lib/MC/MCAsmStreamer.cpp
Line count, exceeded timeout: ./external/syzkaller/vendor/golang.org/x/net/idna/tables.go
Line count, exceeded timeout: ./external/tensorflow/tensorflow/compiler/xla/service/hlo_parser_test.cc
Line count, exceeded timeout: ./frameworks/base/tools/aapt2/configuration/ConfigurationParser_test.cpp
Line count, exceeded timeout: ./frameworks/ml/nn/runtime/test/specs/V1_0/mobilenet_quantized.mod.py
Line count, exceeded timeout: ./packages/apps/UnifiedEmail/tests/src/com/android/mail/utils/AdvancedHtmlSanitizerTest.java
Line count, exceeded timeout: ./packages/apps/UnifiedEmail/tests/src/com/android/mail/utils/BasicHtmlSanitizerTest.java
Line count, exceeded timeout: ./prebuilts/go/linux-x86/src/cmd/dist/build.go
Line count, exceeded timeout: ./prebuilts/go/linux-x86/src/internal/x/net/idna/tables.go
Line count, exceeded timeout: ./prebuilts/go/linux-x86/src/net/http/requestwrite_test.go
Line count, exceeded timeout: ./prebuilts/go/linux-x86/src/regexp/exec_test.go
Line count, exceeded timeout: ./tools/dexter/testdata/expected/large.asm
Line count, exceeded timeout: ./tools/metalava/src/main/java/com/android/tools/metalava/model/psi/Javadoc.kt
Line count, exceeded timeout: ./tools/metalava/src/test/java/com/android/tools/metalava/ApiFromTextTest.kt
Line count, exceeded timeout: ./tools/metalava/src/test/java/com/android/tools/metalava/ConvertTest.kt
Line count, exceeded timeout: ./tools/metalava/src/test/java/com/android/tools/metalava/JDiffXmlTest.kt
github.com/AlDanial/cloc v 1.82 T=5854.21 s (62.9 files/s, 19694.1 lines/s)
----------------------------------------------------------------------------------------
Language files blank comment code
----------------------------------------------------------------------------------------
C/C++ Header 63274 2064490 3535716 19170733
C++ 54318 2765766 2829833 17961649
Java 78470 2299920 4351883 12147841
C 31001 1674311 2172222 10098819
XML 53032 310564 685144 6665510
Python 19023 840748 1217372 3437468
Assembly 7683 464898 777302 3004573
HTML 5169 177319 31949 2434829
Go 7954 219987 354213 2289743
JSON 2007 464 0 1133742
Bourne Shell 5089 161016 205425 971087
PO File 292 303293 294135 898367
Maven 6782 14494 20131 505810
Perl 968 28660 29933 310325
reStructuredText 1744 208757 233667 298584
m4 466 28951 12899 271785
make 6900 70479 90402 258648
Markdown 3328 75589 3 229439
RobotFramework 9 4 5 229335
vim script 1601 35584 43306 223683
Pascal 244 34483 979535 216978
Objective C 1721 40109 93618 189823
C# 1141 22224 41766 171089
JavaScript 599 19683 33262 144845
CMake 1642 28245 26009 144688
Windows Module Definition 568 14695 766 133689
MSBuild script 253 220 140 116404
Rust 948 12214 12732 113035
Kotlin 495 10013 16154 69765
CSS 318 10946 4593 66077
Protocol Buffers 1022 21187 50080 63719
YAML 1130 3024 7313 54703
diff 150 319 2493 48346
SVG 93 53 33 44080
Bourne Again Shell 960 8964 14340 43932
OpenCL 177 3364 5329 43651
Objective C++ 587 10331 28417 43214
Fortran 77 63 77 19999 42841
SWIG 350 6371 6621 35370
Ruby 233 7268 6977 34265
GLSL 903 8282 2202 34048
yacc 34 3591 2515 31021
PHP 186 2909 7433 30965
Lua 126 2711 2441 24106
TeX 78 3737 9258 23697
ANTLR Grammar 520 4135 3036 22939
OCaml 150 4638 7134 20236
Gradle 481 4192 3001 18481
IDL 143 1623 0 18477
TypeScript 182 2745 4507 16860
Groovy 259 4427 9576 16216
XSLT 69 1664 1208 15882
Sass 214 2966 2358 15186
XSD 217 2111 3906 14782
DOS Batch 328 3221 1523 14096
CUDA 85 1379 1741 13654
NAnt script 164 1404 36 13051
Ada 148 2165 6997 12011
Windows Resource File 461 1838 1494 10464
DTD 57 2830 6786 9749
Starlark 57 1368 2628 9000
Ant 94 1872 2683 8319
Glade 3 58 109 8093
XHTML 5 591 22 5876
awk 67 478 1410 5869
Smalltalk 11 382 1 5498
Jupyter Notebook 39 0 20496 5357
Dart 13 840 359 4913
lex 23 939 915 4861
D 233 495 48 4573
INI 85 482 68 4400
Visual Basic 29 616 1383 3903
Lisp 38 635 1041 3737
ActionScript 56 860 2550 3715
Qt 7 0 2 3678
JSP 23 240 436 3126
Freemarker Template 53 717 496 3122
Dockerfile 139 984 2132 2988
Expect 78 408 514 2795
SQL 84 277 556 2688
dtrace 14 358 62 1774
Swift 21 316 493 1766
WiX source 51 161 40 1713
ProGuard 60 687 1312 1411
Mako 15 190 173 1397
MATLAB 19 262 317 1292
Qt Linguist 1 4 0 1258
Scheme 5 43 94 1184
Qt Project 11 81 11 1013
sed 23 22 214 873
Velocity Template Language 5 96 66 747
Julia 1 164 450 720
Vuejs Component 4 76 51 648
PowerShell 16 143 221 637
Forth 1 407 1 630
Prolog 1 386 0 609
Jam 27 170 379 591
Cython 9 174 173 587
AsciiDoc 1 185 1 580
Arduino Sketch 3 77 39 497
Verilog-SystemVerilog 1 354 0 476
Smarty 1 4 0 414
WebAssembly 2 97 0 356
DAL 1 400 263 309
Gencat NLS 5 44 0 301
C Shell 6 36 41 268
Korn Shell 2 40 46 226
F# 6 48 0 191
WiX string localization 11 28 0 188
Clean 1 11 0 168
Apex Class 1 30 0 167
ERB 1 25 0 101
Kermit 3 4 20 83
R 1 12 22 79
TOML 4 20 27 77
ColdFusion 2 9 0 64
Fish Shell 1 13 15 47
HLSL 2 3 3 45
Tcl/Tk 2 11 11 39
SAS 1 14 22 32
MXML 1 10 0 23
Windows Message File 2 5 0 22
Fortran 95 1 3 0 18
Rexx 1 17 2 8
Fortran 90 3 1 263 8
PL/M 1 0 0 7
Standard ML 7 0 0 7
----------------------------------------------------------------------------------------
SUM: 368104 12079135 18355550 84858567
----------------------------------------------------------------------------------------

            Presque autant de Java que de C++ et de C :-) (même si, d'accord, c'est peut-être du Java avec des spécificité...)

            • [^] # Re: Hmm

              Posté par . Évalué à 3.

              Après trois quarts d'heure de récupération des sources de LineageOS 17.1 (Android 10) et une heure trois quart de comptage de lignes de code (cloc), voici les résultats

              Je suis sincèrement désolé que tu ai perdu autant de temps sur quelque chose d'aussi inutile que futile...

              Java c'est 3 choses différentes :

              • un langage de programmation : la syntaxe, la grammaire et sa sémantique (entre autre)
              • une plateforme : c'est le runtime généralement OpenJDK
              • un écosystème : en très gros maven central et quelques outillages

              Quand je lis :

              Onedev : une alternative légère à GitLab

              Au vu des copies d'écran et sachant que c'est du Java, j'ai quand même du mal à voir comment on peut parler de légèreté :p

              Pour moi il est question du second, il veut dire qu'à l'exécution java c'est lourd. C'est aussi ce qui ressort des autres commentaires qui suivent.

              Android n'utilise pas le runtime de java. Il se sert de certains outils qui font parti d'OpenJDK (comme javac, le compilateur C1 de java), mais à l'exécution le runtime java n'est pas impliqué, il n'y a même plus du bytecode java.

              Android lui utilise qu'une vielle version du langage de programmation (java 7 a 9 ans, il y a eu 7 versions depuis) et une partie de l'écosystème.

              La comparaison avec C et C++ n'est évidement pas parfaite, mais c'est 2 langages vivent avec une compatibilité partielle et une partie de l'écosystème commun. Maintenant les sémantiques de chacun sont un peu différente, mais ça commence à être le cas aussi entre Java7 d'Android et Java14 qui sort la semaine prochaine. Par exemple avec le switch ou l'ajout de mot clef.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Hmm

                Posté par (site web personnel) . Évalué à 4. Dernière modification le 06 février 2020 à 15:20.

                Ne t'inquiète pas pour mon temps, je peux faire d'autres trucs pendant que mon ordi exécute des tâches. Et puis, ça avait vraiment piqué ma curiosité :-)
                Et il se peut que je bidouille un peu avec ce code.

                Merci pour tes clarifications, je comprends mieux ce que tu veux dire.

                à l'exécution java c'est lourd

                J'ai surtout l'impression que ça ne vient pas tant du runtime OpenJDK que de ce qu'on en fait. Pour l'avoir utilisé sans framework, avec des petits programmes, ce n'était pas particulièrement lourd, et ça ne fuite pas gratuitement sans raison (par contre, le temps de démarrage peut être long pour des exécutions courtes).

                • [^] # Re: Hmm

                  Posté par . Évalué à 3.

                  Ne t'inquiète pas pour mon temps, je peux faire d'autres trucs pendant que mon ordi exécute des tâches.

                  Tant mieux :)

                  J'ai surtout l'impression que ça ne vient pas tant du runtime OpenJDK que de ce qu'on en fait. Pour l'avoir utilisé sans framework, avec des petits programmes, ce n'était pas particulièrement lourd, et ça ne fuite pas gratuitement sans raison (par contre, le temps de démarrage peut être long pour des exécutions courtes).

                  Entièrement d'accord. Le temps de démarrage est long, mais le runtime lui-même est plus tôt rapide à l'exécution. En terme de mémoire il y a un overhead lié au modèle mémoire de java. Mais c'est rarement ce qui est incriminé. Tu peux avoir aussi certaine lenteur dans des cas pathologiques de création d'un grands nombres d'objets d'un coup. Le dernier point qui peut être gênant c'est le GC qui peut faire de stop the world, mais à moins d'utiliser des tailles de heap vraiment grande je n'ai personnellement jamais rencontré de cas où ça posait un problème.

                  À coté de ça l'écosystème n'a pas que des bonnes pratiques avec l'utilisation de proxy dynamique et de réflexion probablement trop importante. Ce qui n'aide pas toujours. Mais c'est un point qui est entrain d'évoluer j'ai l'impression quand on voit arriver des micronaute, vertx ou quarkus.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Hmm

            Posté par (site web personnel) . Évalué à 1.

            Quel est le rapport entre java et android ? Le langage se ressemble ? Il utilise le bytecode java dans l'une de ses étapes de build ?

            Déjà je n'ai pas dit Android, j'ai dit développement Android ce qui n'est pas la même chose. Si tu n'as jamais lancé Android Studio, je t'invite à le faire pour te construire ta propre idée. Des comparaisons j'en ai donné, il ne s'agit pas d'un troll gratuit.

            Red5, Tomcat sont bien des applications que j'ai du faire tourner en local et sur un serveur donc je sais de quoi je parle. Aussi, tu n'imagines pas le temps nécessaire pour « déployer » un simple changement dans notre application web en Java dans mon ancienne entreprise.

            Je n'ai jamais dit que Python était bien, je n'aime pas ce langage. Java est lourd et gourmand en mémoire c'est un fait comme beaucoup de langages (semi-)interprétés. Ruby n'est pas mieux, mon redmine me demande beaucoup de CPU et de RAM et j'aurais bien aimé qu'il soit codé aussi dans une autre technologie.

            En comparaison, nodejs (bien que je n'aime pas cette technologie) est basée sur v8, une implémentation JIT de ECMAScript et pas si énergivore (du moment qu'on sait coder, comme d'habitude). Je fais tourner etherpad sur mon serveur, il consomme effectivement ~250 Mo de RAM, mais ça reste largement en dessous de ce que j'ai pu subir lorsque j'ai fait tourner Tomcat/Red5.

            AI is a mental disorder

  • # Stagit?

    Posté par (site web personnel) . Évalué à 7.

    Stagit est un projet de suckless:

    https://git.2f30.org/stagit/

    C'est un compilateur de pages statiques pour visualiser Git.

    Ca ne supporte pas les branches, mais c'est super light.

    Mais il faut regenerer les pages a chaque commit...

    • [^] # Re: Stagit?

      Posté par (Mastodon) . Évalué à 4.

      J'allais dire un truc intelligent avant de réaliser que ça ne l'était pas...
      Le concept est sympa, mais il y a l'inconvénient de :

      Mais il faut regenerer les pages a chaque commit...

      Et là je me suis dis « Eh, ya quelques années, j'ai bidouillé bashttpd pour répondre à des webhooks git pour agir en cas de commit, tags etc. »
      L'idéal : on met un webhook sur commit, qui pointe sur le bashttpd, qui exécute un script shell, qui va mettre à jour stagit, au poil.

      Bon, c'est là que ça devient crétin : le webhook est envoyé par une forge type gitlab, donc on héberge sur gitlab pour avoir un webhook sur commit pour mettre à jour stagit...

      Bref, je ne suis pas assez calé en git côté serveur pour savoir si on ne peut pas mettre en place, justement, un hook quelconque en cas de commit.

      C'est ce qu'on appelle une fausse bonne idée...
      Sur ce, je retourne à mon arrêt de travail, visiblement c'pas pour rien que le médecin me laisse pas retourner bosser immédiatement...

      Yth ..:)

      • [^] # Re: Stagit?

        Posté par . Évalué à 2.

        Bref, je ne suis pas assez calé en git côté serveur pour savoir si on ne peut pas mettre en place, justement, un hook quelconque en cas de commit.

        La solution moche, ça serais un script de ce goût la:

        REPO="${1:?"need the repo as param 1"}"
while true
do
 inotifywait -r $REPO
 whatever()
done

        mais je soupçonne git d'avoir un hook dédié, ce qui serais nettement plus propre et performant, par exemple .git/hooks/pre-receive, mais je ne suis pas sûr de mon coup.

        • [^] # Re: Stagit?

          Posté par (Mastodon) . Évalué à 2.

          mais je soupçonne git d'avoir un hook dédié, ce qui serais nettement plus propre et performant, par exemple .git/hooks/pre-receive, mais je ne suis pas sûr de mon coup.

          C'est plutôt à ce genre de solution que je pensais, un truc passif plutôt qu'un démon-like qui attendrait que quelque chose se passe.

          Yth.

  • # Kallithea ?

    Posté par . Évalué à 2.

    Ce projet semble effectivement très fournis en fonctionnalités, c'est très intérrésant !

    Actuellement j'utilise Kallithea qui est écris en Python et que je trouve très léger et pas trop compliqué à maintenir: kallithea-scm

    • [^] # Re: Kallithea ?

      Posté par . Évalué à 3. Dernière modification le 07 février 2020 à 10:34.

      Intéressant mais il ne couvre pas le ticketing.
      Sur le même plan il y a scm-manager:
      scm-manager.
      Il est super simple à installer et peut servir pour ouvrir son repo git local à la manière de hg serve avec gestion des permissions en prime ou installé en tant que serveur. Il tient bien la charge. Nous l'avons utilisé pour gérer plusieurs centaines de dépôts et d'utilisateurs pendant 2 ans avant de basculer sous Bitbucket.

      Peut-on intégrer Kalithea avec un outil de ticketing ?

  • # Pre-requis

    Posté par . Évalué à 1. Dernière modification le 07 février 2020 à 15:08.

    Quels sont les pré-requis (hard soft) ? Onedev est-il installable sur les nanomachines ? (gitlab ne l'est pas a cause de sa surconso de ram si je ne m'abuse)
    Onedev nécessite-t-il la permission executer sur les fichiers data ?

    Merci pour la présentation. 😉

    • [^] # Re: Pre-requis

      Posté par . Évalué à 10.

      Hello, OneDev author here. Sorry for not being able to answer in French.

      For personal projects, a box with 1G memory should be enough. However if your git repository is large, you will need more memory. For instance, 2G memory is enough for OneDev to manage the 1.7G linux repository.

      I am not sure what do you mean about "require permission to execute on data files", can you please elaborate?

      • [^] # Re: Pre-requis

        Posté par (site web personnel) . Évalué à 5. Dernière modification le 08 février 2020 à 09:51.

        Traduction rapide :

        Pour les projets personnels, un ordi avec 1 GiB de mémoire devrait être suffisant. Cependant si votre dépôt git est gros, vous aurez besoin de plus de mémoire. Par exemple, 2 GiB de mémoire est suffisant pour que OneDev gère les 1,7 GiB du dépôt linux.

        Je ne suis pas sûr de ce que vous voulez dire avec 'Onedev nécessite-t-il la permission executer sur les fichiers data ? ', pouvez-vous préciser ?

        (J'imagine qu'il s'agit du noexec sur la partition hébergeant le dépôt gît // my guess is noexec option on the git repo hosting partition)

        • [^] # Re: Pre-requis

          Posté par . Évalué à 2. Dernière modification le 09 février 2020 à 16:09.

          (J'imagine qu'il s'agit du noexec sur la partition hébergeant le dépôt gît // my guess is noexec option on the git repo hosting partition)

          C'est encore plus simple/relou que cela : le cluster qui gère les services passe par un serveur de stockage distant via SSHFS et SSHFS refuse obstinément de transmettre la permission exec. (malgré un "sudo setfacl -dRm u::rwx,g::rwx /media/folder" sur la remote machine et d'avoir bidouillé la config sshf du client)

      • [^] # Re: Pre-requis

        Posté par . Évalué à 3.

        Hello.

        I am not sure what do you mean about "require permission to execute on data files", can you please elaborate?

        From what I understand, I think he says gitlab needs execution rights on files in /var, which might be a problem on a computer where /var is mounted with options to forbid execution of files. I may be wrong, though.

        Et en français:

        De ce que je comprend, je pense qu'il dis que gitlab nécessite les droits d'exécution de certains fichiers dans /var, ce qui peut être un problème quand /var est monté avec des option pour empêcher l'exécution de fichiers. Je peux me tromper, cependant.

        • [^] # Re: Pre-requis

          Posté par . Évalué à 7.

          OneDev does not need any permission over other folders/files except for the folder used to run OneDev. It is a "green" software not requiring to be installed into the system via package system.

  • # Build and Job Executor

    Posté par . Évalué à 4.

    Je commence à faire le tour de OneDev et l'un des points qui n'existait pas sous redmine est la partie Build/Deploy.

    Sous OneDev, ça apparait avec les notions de Build et Job Executor : Kubernetes Executor ou Docker Executor.

    Nous avons 2 types de projets :
    - Appli Web en PHP (symfony)
    - Appli Web dotnet (C#)

    Est-ce que ça peut nous permettre de compiler, faire des bundles et déployer ? Si oui, comment ? Je suis preneur du peu d'explication que je pourrais avoir :)

    • [^] # Re: Build and Job Executor

      Posté par . Évalué à 9.

      As long as you can compile/bundle/deploy your projects from a docker container, you can do the same in OneDev. OneDev supports both linux and windows containers, so I guess it has a large chance to support your PHP and Dotnet projects.

      • [^] # Re: Build and Job Executor

        Posté par . Évalué à 3.

        Je me permets une traduction (je ne suis pas traducteur):

        Tant qu'il est possible de compiler, empaqueter(1), déployer les projets depuis un conteneur docker, il est possible de le faire avec OneDev. OneDev supporte tant les conteneurs Linux que Windows(2) dont je suppose qu'il y a de grandes chances qu'il supporte les projets basés sur PHP ou .NET (3).

        1: je suis pas sûr de la traduction sur ce terme
        2: Je suppose qu'il parle ici d'un environnement GNU/linux, mais il est très possible que ça soit valide pour d'autre systèmes basés sur le noyau linux.
        3: .Net: DotNet.

      • [^] # Re: Build and Job Executor

        Posté par . Évalué à 4.

        Thanks for your help Robin.

        OneDev support only container or we can call external script (.bat, .exe, .js) to do the job ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.