Onedev : une alternative légère à GitLab

# Complet

Posté par bux (site web personnel, Mastodon) le 04 février 2020 à 15:38. É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 dnanar le 04 février 2020 à 17:10. É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 El Titi le 04 février 2020 à 17:35. É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 dnanar le 04 février 2020 à 17:47. É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 El Titi le 04 février 2020 à 21:35. Évalué à 3.
    
    Là c'est plus cohérent.
[^] # Re: Sourcehut

Posté par stopspam le 04 février 2020 à 17:37. É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 El Titi le 04 février 2020 à 17:43. Évalué à 8.
  
  https://linuxfr.org/news/git-bug-un-bug-tracker-distribue-integre-dans-git
  
  Par contre tu n'auras que la gestion des tickets.
  
  Onedev et consors bien que "centralisés" offre un éventail de fonctionnalités bien plus large avec l'intégration et le déploiement en continu, la revue de code entre autres.
- [^] # Re: Sourcehut
  
  Posté par Bruno (Mastodon) le 04 février 2020 à 21:24. Évalué à 3.
  
  A priori avec Tuleap tu pourrais importer les tickets Redmine https://docs.tuleap.org/installation-guide/import.html
  - [^] # Re: Sourcehut
    
    Posté par stopspam le 04 février 2020 à 22:07. Évalué à 2.
    
    Merci pour 2 réponses, intéressant. En parallèle je lorgne sur l'outil présenté en annonce. Je le teste demain sur une VM.
    - [^] # Re: Sourcehut
      
      Posté par stopspam le 04 février 2020 à 22:20. Évalué à 6.
      
      Je ne suis pas branché java mais c'est bien la première fois que je vois un packaging aussi simple dans l'installation, la mise à jour où les migrations de base. Un seul script à chaque fois qui fait la magie ;) c'est cool !!
[^] # Re: Sourcehut

Posté par David Demelier (site web personnel) le 05 février 2020 à 10:52. Évalué à 7.

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

git is great because linus did it, mercurial is better because he didn't
[^] # Re: Sourcehut

Posté par vv222 le 05 février 2020 à 11:27. É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 Maz (site web personnel) le 11 février 2020 à 11:49. É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 stopspam le 05 février 2020 à 01:15. É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 stopspam le 05 février 2020 à 01:22. Évalué à 2.

sous windows, problème de droits visiblement…
- [^] # Re: 1er lancement foireux
  
  Posté par stopspam le 05 février 2020 à 11:03. É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 gnumdk (site web personnel) le 05 février 2020 à 07:07. É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 ZeroHeure le 05 février 2020 à 09:39. É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 David Demelier (site web personnel) le 05 février 2020 à 10:54. É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.

git is great because linus did it, mercurial is better because he didn't
- [^] # Re: Hmm
  
  Posté par aiolos le 05 février 2020 à 12:01. É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 raphj le 05 février 2020 à 11:23. É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 David Demelier (site web personnel) le 05 février 2020 à 14:07. É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.

git is great because linus did it, mercurial is better because he didn't

[^] # Re: Hmm

Posté par raphj le 05 février 2020 à 14:36. É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 Anonyme le 05 février 2020 à 15:42. É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 barmic 🦦 le 05 février 2020 à 23:16. É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 barmic 🦦 le 05 février 2020 à 23:25. É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 Yth (Mastodon) le 06 février 2020 à 10:49. É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 Vincent Danjean le 06 février 2020 à 11:23. É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 barmic 🦦 le 06 février 2020 à 12:15. É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 raphj le 06 février 2020 à 12:54. É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 barmic 🦦 le 06 février 2020 à 14:21. É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 raphj le 06 février 2020 à 15:19. É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 barmic 🦦 le 06 février 2020 à 15:47. É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 David Demelier (site web personnel) le 06 février 2020 à 16:52. É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.

git is great because linus did it, mercurial is better because he didn't

# Stagit?

Posté par Benjamin Henrion (site web personnel) le 05 février 2020 à 10:45. É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 Yth (Mastodon) le 05 février 2020 à 14:15. É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 freem le 07 février 2020 à 12:03. É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 Yth (Mastodon) le 08 février 2020 à 17:49. É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 jujubickoille le 06 février 2020 à 20:44. É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 El Titi le 07 février 2020 à 10:32. É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 voxdemonix le 07 février 2020 à 15:05. É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 robinshen le 08 février 2020 à 06:39. É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 Benoît Sibaud (site web personnel) le 08 février 2020 à 09:50. É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 voxdemonix le 09 février 2020 à 16:06. É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 freem le 08 février 2020 à 22:08. É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 robinshen le 09 février 2020 à 02:08. É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 stopspam le 07 février 2020 à 17:19. É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 robinshen le 08 février 2020 à 06:42. É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 freem le 08 février 2020 à 22:17. É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 stopspam le 10 février 2020 à 10:39. Évalué à 4.
  
  Thanks for your help Robin.
  
  OneDev support only container or we can call external script (.bat, .exe, .js) to do the job ?
  - [^] # Re: Build and Job Executor
    
    Posté par robinshen le 10 février 2020 à 13:18. Évalué à 4.
    
    Currently it only supports to run builds inside containers.
    - [^] # Re: Build and Job Executor
      
      Posté par stopspam le 10 février 2020 à 15:13. Évalué à 4.
      
      Ok, so i have to install docker or other alternative. Thanks.

Aller plus loin