Gitea: Discussion de la feuille de route de Gitea

Une solution de plugin (y compris le thème) pour étendre gitea.

Serait-il possible d'ajouter des packages de système d'exploitation appropriés au processus de construction ? J'ai essayé de mettre en place quelque chose pour fedora, mais aller semble un peu compliqué à emballer. #31 en parle mais semble toujours ouvert.

Nous utilisons ansible pour déployer l'archive tar sur le système Debian, ce n'est pas très pratique mais ça marche. Des référentiels pour les distributions les plus courantes seraient bien, mais ils doivent être mis en place et maintenus.

Quelques suggestions :

• Possibilité d'intégrer automatiquement Drone CI/CD dans Gitea pendant le processus de construction.
• Plus de configurabilité de l'administration du site à partir de l'interface utilisateur de Gitea, après l'installation. Par exemple, j'aimerais pouvoir modifier les éléments dans _Configuration du service_ à partir de la page _Configuration_.
• Option pour masquer un utilisateur de la page Explorer.

Pull request fédérés / problèmes / forks

Pull request fédérés / problèmes / forks

Peut-être pas fédéré au sens Fediverse du terme (ActivityPub, OStatus, diaspora*, etc.) mais j'aimerais pouvoir interagir avec des instances distantes de la sienne mise en œuvre de la manière qui convient le mieux au projet.

Il peut également être intéressant d'avoir des équipes et des organisations composées d'utilisateurs provenant de plusieurs instances, bien que cela soit probablement incroyablement difficile à mettre en œuvre.

Deux suggestions du POV d'un utilisateur final avec des compétences de codage minimales qui essaie d'aider les projets open source que j'utilise en signalant des bogues et en donnant des commentaires UX :
1) Aidez à standardiser ForgeFed ! J'aimerais que l'UX du dépôt de bogues sur l'instance de Gitea (et d'autres forges de code hébergées par la communauté) ressemble à un énorme GH décentralisé.
2) Faites de chaque partie d'un projet un dépôt Git, de sorte que les problèmes, le wiki, etc. GL et sr.ht le font avec au moins certains de leurs composants. En plus d'être utile, cela pourrait potentiellement aider avec le point 1)

La possibilité de répondre aux tickets par e-mail serait un grand pas en avant pour la convivialité

Autoriser l'édition de toutes les configurations à partir de l'interface utilisateur (et peut-être modifier le format du fichier de configuration au cours du processus)

Peut-être stocker la majorité de la configuration dans la base de données et fournir le cli et l'API appropriés pour cela

@sapk @tboerger Je dirais que nous devrions passer à viper pour la configuration, de cette façon nous pourrions nous débarrasser d'ini (et de certains des bugs que nous avons eus avec) et obtenir des trucs comme recharger la configuration pendant que Gitea est en cours d'exécution et des variables d'environnement appropriées .

Je serais prêt à m'y attaquer, mais je ne sais pas si je trouverai le temps dans un avenir proche.

Je suis pour Viper aussi. J'essayais de le faire il y a 2 ans, mais je n'ai pas eu le temps de le finir... mais je peux réessayer :)

Je suis pour obtenir un fichier de configuration plus minimal... Beaucoup de ces paramètres n'ont pas besoin d'être définis via un fichier de configuration statique et pourraient être facilement ajoutés à la base de données et mis en cache pour des raisons de performances.

Je pense que nous pourrions d'abord ajouter une table de configuration de base de données et y déplacer la plupart des éléments de configuration modifiables du fichier ini et ne laisser que les éléments qui doivent être rechargés.

@lunny and all : acceptez de déplacer de nombreux paramètres vers la base de données et de les laisser configurer dans l'interface Web (au niveau du site ou du référentiel) est un bon pas en avant. Il serait également facile d'avoir un outil comme tea ou gitea lui-même capable de modifier ces valeurs à partir de la ligne de commande, de sorte que vous puissiez toujours scripter une configuration par défaut.

Le système de module sonne bien. Je crois qu'il y a beaucoup de gens prêts à ajouter de nouvelles fonctionnalités à gitea.

@belliash @sapk Les plugins/modules IMO ne peuvent pas être implémentés efficacement sans refactoriser complètement le package de modèles et ajouter plus d'abstraction. J'ai testé plusieurs technologies comme la prise en charge native des plugins de Go.

Le résultat a été des binaires géants qui dépendent fortement du binaire Gitea.

Je pense qu'il est plus réaliste d'améliorer la prise en charge des webhooks et d'ajouter des pages personnalisées par webhooks, car nous avons déjà une API mature et silencieuse qui peut être utilisée pour les opérations de base de données.

@jonasfranz Je serais très favorable à la refactorisation des modèles pour supprimer une grande partie de ses dépendances.

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

révèle 98 (!) importations directes. 50 d'entre eux sont des noyaux non go.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

révèle 437 (!!) dépendances transitives. (dont 304 core non go)

Regardez la source du drone, nous avons là beaucoup de trucs enfichables basés sur des webhooks.

A côté de cela, un modèle de plugin comme packer a du sens, un système de plugin basé sur grpc.

@tboerger Pouvez-vous fournir un exemple de matériel enfichable de drone ? Vous voulez dire le système de plugins basé sur des images docker ?

Je parle des extensions pour les configs, secrets et ainsi de suite, les interfaces doivent être définies sur https://github.com/drone/drone/tree/master/plugin

Je suis d'accord avec vous, la prochaine grande étape de Gitea devrait être le système de plugins. J'y pense aussi ces jours-ci. Je vais essayer le système de plugin.

Je pense que cela devrait être similaire avec le système de plugin de drone mais en avoir plus. Nous devons permettre à un plugin d'avoir une interface utilisateur et de se connecter automatiquement avec OAuth2 de Gitea. Et nous devrions avoir une politique de sécurité sur les plugins. et etc.

Je souhaite partager un tableau de comparaison que nous avons créé vers 2016 pour _décider_ quelle plate-forme d'hébergement choisir pour la Open Source Geospatial Foundation. Dans ce tableau, nous avons répertorié les fonctionnalités qui étaient importantes pour nous. Gitea est dans l'une des colonnes :

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

Vous verrez qu'une fonctionnalité importante qui manquait en 2016 est toujours manquante aujourd'hui : la réponse par courrier (commentaire/réponse) --- d'autres ont été implémentées dès aujourd'hui.

L' outil migrate from github et Comments on diff lines sont terminés.

Besoin de personnalisation de modèle de courrier
Voir #6037

Il y a donc déjà pas mal de personnalisation de modèle possible - la ligne d'objet est la seule chose que je ne pense pas que nous ayons.

Ce que nous devrions vraiment faire, cependant, c'est d'activer i18n pour les e-mails et les messages git serv hook.

L'annulation d'une demande d'extraction est nécessaire.
Voir #6375

Prise en charge complète des balises dans l'interface utilisateur. Créer, attribuer, modifier, supprimer, etc. Cette fonctionnalité me manque vraiment.

Je suis en faveur de la configuration dans la base de données (avec cli ou api pour la configurer, comme créer l'utilisateur et l'authentification LDAP, etc.) et le système de plugins.
Ces deux-là devraient faire faire un grand pas à gitea.

EPA

• [x] Nous avons besoin d'un moyen de gérer les fichiers LFS dans un référentiel - à l'heure actuelle, ils sont totalement opaques. #7199 est une tentative de fournir cela - mais pour être efficace, il faut probablement...
  
  
  
  • [ ] Filtre Bloom pour la recherche de blob - ce serait très bien d'avoir un moyen légèrement efficace de trouver le commit et à quel chemin d'arbre qui a introduit un blob
  
  
• [ ] À l'heure actuelle, il n'existe aucun moyen fiable de redémarrer un téléchargement vers LFS - les téléchargements très volumineux peuvent donc échouer à plusieurs reprises. Implémentez tus.io selon #1723
• [ ] Nous devrions fournir une option pour utiliser uniquement les attributs .git pour déterminer si un fichier est un pointeur LFS plutôt que de simplement supposer que tout fichier qui ressemble à un pointeur est un pointeur. Bien que cela soit susceptible de rendre la fonctionnalité dans #7199 très difficile ...
• [ ] Les fichiers LFS doivent être visibles dans la vue diff.

Durcissement

Arrêt et début de la mise en cluster de Gitea

• [ ] Nous devons durcir la réponse de Gitea à l'arrêt.
  
  
  
  • [x] Cela signifie un arrêt gracieux des connexions d'écoute, en particulier le SSH intégré - qui pourrait actuellement entraîner la corruption des référentiels git par un arrêt brutal. #7274 est le début d'une tentative pour résoudre ce problème.
  
  
  • [ ] mais cela signifie également que les tâches de notification doivent être sérialisables - par exemple, les files d'attente d'indexation doivent passer par des files d'attente sur disque ou de base de données, de la même manière des files d'attente de courrier, etc. Nous en avons déjà une partie, mais ces files d'attente ne s'arrêtent pas normalement.
  
  
• [ ] En corollaire de ce qui précède, il convient de séparer l'action d'indexation de la recherche. Un arrêt gracieux l'exige dans tous les cas - mais cela fait partie de l'étape vers le clustering. Je ne sais pas quelle architecture nous devrions prendre, mais il existe plusieurs options - séparer l'indexeur dans un processus séparé et faire en sorte que Gitea soit en lecture seule l'index, ou exporter l'ensemble de l'indexation.

Diff et lecture de données de longueur arbitraire dans la mémoire

• [ ] Le code Diff a besoin d'être refactorisé - il est fragile, lit l'intégralité du diff en mémoire et nécessite que d'énormes diff soient analysés par le navigateur avant que l'utilisateur puisse répondre. Cela nécessite à la fois des modifications de l'interface utilisateur et du serveur - vraisemblablement, un défilement infini soutenu par Ajax est la bonne technique pour cela. À l'heure actuelle, un grand diff suffisamment mauvais pourrait arrêter à la fois le serveur et le navigateur.
• [ ] Notre architecture diff pollue actuellement le référentiel de base avec des branches et des objets pré-fusionnés.
• [ ] En général, nous DEVONS arrêter de simplement lire des données de longueur arbitraire en mémoire. S'il y a un endroit où le navigateur peut vouloir cela, nous devons limiter ce que nous lisons, puis utiliser une technique de défilement infini ou un lien complet avec le rendu du navigateur ou rendu dans un pipeline pour nous assurer qu'il n'est pas entièrement mis en mémoire tampon. Même le code relativement nouveau souffre encore de ce problème.
• [ ] (Si nous exécutons un processus git qui peut renvoyer des données arbitrairement longues, nous devrions essayer d'éviter de tout lire directement dans un tampon stdout mais faire plus de pipelines go-routine.)

Fusionner

• [ ] Nous devons refactoriser la fusion pour utiliser entièrement l'index git, car nous effectuons actuellement une vérification clairsemée pour la fusion - essentiellement parce que git merge tombera sur https://git-scm.com/docs/git-merge-one-file pour gérer les fusions non rapides. Cela force la création de chemins semi-arbitraires sur le serveur - qui sont inutiles et dépendent des facteurs jeu de caractères/système de fichiers. Ce n'est pas nécessaire de faire cela - nous pouvons faire ces fusions avec des fichiers temporaires, hacher et ajouter directement à l'index.

Emplacements d'échappement et de dépôt

• [ ] Il faut vérifier partout pour s'échapper. Le code hérité de Gogs a été mal échappé en général et a été responsable de plusieurs problèmes de sécurité.
• [ ] L'hypothèse selon laquelle les noms de nom d'utilisateur et de référentiel n'ont pas besoin d'être échappés nous force à prendre une décision d'architecture dont nous n'avons pas besoin. Il ne nous a même pas protégés correctement pour les signatures git, d'où le #5774.
• [ ] Bien qu'il soit agréable pour les utilisateurs d'avoir l'emplacement du référentiel sous-jacent correspondant à l'emplacement du système de fichiers - par exemple $GITEA_ROOT/owner/reponame c'est une mauvaise décision architecturale à mon humble avis et conduit à supposer par les utilisateurs que nos référentiels peuvent toujours être utilisés par git sur le serveur sans plus loin - ILS NE DEVRAIENT PAS. Nous devrions passer à $GITEA_ROOT/repository-$ID , éventuellement fragmenté. (Cela permettrait de supprimer de nombreux appels vers repo.MustOwner() ou repo.GetOwner() )
  
  
  
  • [ ] Une fois que nous sommes passés à ce qui précède et que nous avons tout échappé correctement, nous pouvons alors assouplir les contraintes sur les noms d'utilisateur et les noms de référentiel - bien que cela doive être soigneusement réfléchi pour s'assurer que nous le faisons d'une manière qui ne permet pas truquer à travers des problèmes similaires à #5774.
  
  
• [x] Nous devrions imposer aux processus git du serveur de fonctionner avec un environnement Gitea suffisant - il y a des utilisateurs répétés qui essaient d'utiliser les référentiels de Gitea sur le serveur sans passer par Gitea, alors se plaignent que Gitea n'est pas mis à jour, etc. #6961 est un étape nécessaire à cela et après la fusion de cela, nous modifions simplement https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 pour appliquer le paramètre de SSH_ORIGINAL_COMMAND ou autrement imposer que le reste de l'environnement standard est défini.
• [ ] Nous devrions être capables de gérer les référentiels montés NO_EXEC - et en fait, nous devrions probablement le recommander. Ce n'est probablement pas vraiment difficile à faire - changez simplement la variable .git/config ou la variable centrale .gitconfig core.hooksPath et réfléchissez à l'endroit où nous allons placer les crochets autrement.
• [ ] Nous stockons essentiellement des lignes de code directement dans la base de données pour les commentaires - ce qui ne fonctionne pas si les données stockées ne sont pas en UTF-8. Cela signifie que vous ne pouvez tout simplement pas commenter un code non UTF8.

API/SDK

• [ ] C'est fou la quantité de travail qu'on doit faire pour construire une API quand on fait tous les efforts pour avoir de l'arrogance. Nous devrions simplement générer cela automatiquement à partir de swagger, ou générer automatiquement autant que possible
• [ ] Nous n'avons aucun moyen de tester une version d'API fixe par rapport à notre développement Gitea, nous ne pouvons donc pas dire quand nous apportons des modifications importantes.
• [ ] Nous devrions pouvoir utiliser une API/SDK généré automatiquement pour créer des harnais de test simples

Essai

• [ ] Nous exécutons actuellement nos tests unitaires au niveau TRACE - cela limite notre capacité à ajouter une trace appropriée aux choses. Depuis https://gitea.com/gitea/log/pulls/3 et si nous rétroportons dans Gitea, nous pouvons changer cela à partir de notre makefile.
• [ ] Besoin de plus de tests unitaires et déterminer si certains des tests d'intégration sont réellement unitaires et vice versa. par exemple https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [ ] Nous avons besoin de plus de tests d'intégration qui essaient de parcourir les user stories. C'est-à-dire - Un utilisateur se connecte, fait X, puis Y et Z se produisent. C'est bien de tester les choses de manière isolée, par exemple. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go mais ce n'est pas vraiment intégré et il manque de tester ce que l'utilisateur expérimente. Je n'arrête pas de le dire, mais d'autres tests devraient ressembler à : https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go et https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go qui teste réellement si une fonctionnalité s'intègre correctement.
• [x] Notre régime de test prend trop de temps - CI prend 30 à 40 minutes pour s'exécuter actuellement ! Nous devrions les exécuter en parallèle.
• [ ] Il n'y a pas de moyen simple de créer des tests de migration.

Aller à l'architecture de paquet

Des modèles

• [ ] code.gitea.io/gitea/models dépend de beaucoup trop de choses que cela doit arrêter.
• [ ] models.x doit être détruit. C'est une décision architecturale terrible.
• [ ] Pour un trop grand nombre de modèles, il est trop facile de provoquer un déréférencement de pointeur nul parce que vous ne savez pas dans quel état il se trouve. Pouvons-nous utiliser le système de frappe de go un peu mieux ici ?
• [x] Nous devrions simplement coller OwnerName dans la table du référentiel car chaque fois que nous obtenons un référentiel, nous devons alors aller chercher le propriétaire. C'est idiot et une perte de temps. Les dépôts ne changent pas très souvent de propriétaire, donc le coût d'avoir à gérer cela n'est pas important.
• [ ] Trop de choses sont encore faites dans les modèles et il faudrait en sortir davantage.
• [ ] Il peut être judicieux de diviser les modèles en noyaux et non-noyaux.

Modules

• [x] Il existe essentiellement deux types de modules : ceux qui dépendent des modèles et ceux dont dépendent les modèles. Séparons-les, l'un pourrait être appelé services.

macaron

• [ ] Je pense que nous devrions prendre au sérieux le passage au gin proposé par @lunny
• [ ] Notre base de code est éclaboussée de dépendances sur macaron cela ne devrait pas être le cas

Réglage

• [ ] Dépend du macaron aussi (!)
• [ ] Est étroitement lié à go-ini, une autre dépendance dont nous devrions envisager de nous déconnecter.

Internationalisation

• [ ] E-mail non internationalisé
• [ ] Messages Git non internationalisés
• [ ] Messages d'erreur non internationalisés
• [ ] Nous devrions automatiser la suppression de la documentation de notre site Web hugo afin qu'elle puisse être internationalisée avec CrowdIn
• [ ] C'est étrange que nous ayons des langues utilisant des formes minuscules, par exemple français, español, dans les listes de sélection de langue - cela représente le début d'une phrase dans chacune de ces langues, donc AFAICS devrait être en majuscule. Oui, si j'écris en français j'écris "français", mais si j'écris une liste à puces, j'écris :
  
  
  
  • Anglais
  
  
  • English
  
  
  • Espagnol
  
  

Gitea Dump & Restaurer

• [ ] Le dump Gitea est cassé pour la conversion entre les variantes SQL
• [ ] Nous n'avons pas de commande de restauration

Concernant la partie UI, je suggérerais de livrer deux UI :

• un HTML simple (similaire à l'actuel sans js)
• un JS complet qui repose uniquement sur l'appel d'API. Cela obligerait à repenser quelques API mais cela permettra également plus d'interaction avec d'autres applications externes.

• pense que nous devrions prendre au sérieux le passage au gin proposé par @lunny

Je suggérerais du go-chi au lieu du gin.

• Nous devrions automatiser la suppression de la documentation de notre site Web hugo afin qu'elle puisse être internationalisée avec CrowdIn

À mon humble avis, le site Web / la documentation ne doivent pas du tout être traduits, ils sont de toute façon toujours obsolètes ...

À mon humble avis, le site Web / la documentation ne doivent pas du tout être traduits, ils sont de toute façon toujours obsolètes ...

Mais avec crowdin, il serait obsolète d'informer les gens et d'invalider les traductions actuelles.

Serait-il possible d'ajouter des packages de système d'exploitation appropriés au processus de construction ? je

Peut-être que les packages de style PPA contrôlés et versionnés par les développeurs de GItea seraient une bonne idée, mais je ne suis pas un fan de la méthode de gestion de version "geler et rétroporter les correctifs de sécurité" de style Debian pour les projets rapides (tels que GItea)

J'aimerais toujours avoir https://github.com/go-gitea/gitea/issues/3840.
Je pense que cela peut être implémenté avec une compatibilité descendante.
Mais cela ne deviendra clair qu'une fois la migration de la nouvelle bibliothèque de routage établie.
Un nettoyage/refactorisation de base préalable faciliterait également les choses.

J'aimerais toujours avoir le #3840.
Je pense que cela peut être implémenté avec une compatibilité descendante.
Mais cela ne deviendra clair qu'une fois la migration de la nouvelle bibliothèque de routage établie.
Un nettoyage/refactorisation de base préalable faciliterait également les choses.

Dans ce cas, il est possible que vous perdiez la prise en charge de Drone, car elle n'est actuellement pas non plus implémentée pour Gitlab.

J'aimerais toujours avoir le #3840.
Je pense que cela peut être implémenté avec une compatibilité descendante.
Mais cela ne deviendra clair qu'une fois la migration de la nouvelle bibliothèque de routage établie.
Un nettoyage/refactorisation de base préalable faciliterait également les choses.

Nous n'avons probablement pas besoin de cette fonctionnalité de groupe pour affecter les URL du référentiel, nous pourrions simplement créer des dossiers dans lesquels le référentiel pourrait être affiché, mais conserver les mêmes URL de référentiel qu'aujourd'hui.

@tboerger
Ma pensée était que l'URL peut rester la même si un référentiel n'est pas imbriqué dans un groupe/répertoire.
Les URL ne doivent être « mises à niveau » que si le référentiel utilise la fonctionnalité de groupe/répertoire.
Mais oui, les dépôts avec les nouvelles URL ne pourraient probablement pas prendre en charge les drones prêts à l'emploi.

@lafriks
Ça a l'air d'être une bonne idée. Mon scénario d'utilisation de la fonctionnalité consiste à héberger des modules Git ou les sous-projets de projets Repo. Donc, je ne suis pas sûr que cela couvre ce cas.

Pas de soucis. Je suis réticent à faire un changement aussi important, et peut-être aussi décisif.

Cette question a beaucoup de bonnes idées et nous devrions les garder et les traiter.
Cependant, quand et comment choisir ? Cette discussion peut durer éternellement.

Je suggérerais soit au propriétaire de choisir les sujets, soit un vote entre eux et les membres.
Qu'est-ce que tu penses?

@DblK C'est vrai. Mais je pense que nous pourrions le faire après avoir migré vers gitea.com. Actuellement, nous avons besoin de plus de commentaires des utilisateurs.

• Support mercuriel
• meilleur tri et filtrage des relations publiques et des problèmes

• Support mercuriel

Non je t'en prie. Il s'appelle "git"ea pour une raison.
Je comprends le désir d'avoir une portée plus large mais
le ballonnement est au coin de la rue...

l'importation mercurielle serait une alternative

Le 26 juillet 2019 13:52:50 UTC, Sandro Santilli [email protected] a écrit :

• Support mercuriel

Non je t'en prie. Il s'appelle "git"ea pour une raison.
Je comprends le désir d'avoir une portée plus large mais
le ballonnement est au coin de la rue...

--
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Pull request fédérés / problèmes / forks

Peut-être pas fédéré au sens Fediverse du terme (ActivityPub, OStatus, diaspora*, etc.) mais j'aimerais pouvoir interagir avec des instances distantes de la sienne mise en œuvre de la manière qui convient le mieux au projet.

Il y a déjà une discussion à ce sujet dans #1612. ForgeFed rassemble quelques idées intéressantes pour faire de la fédération des forges de code comme Gitea. Ce serait génial si ce serait la prochaine grande fonctionnalité de Gitea !

J'aimerais un outil de comparaison visuelle pour les fichiers graphiques (JPEG, PNG, mais aussi PDF), similaire à ce que propose Github .

Nous avons déjà un PR pour diff images

Nous avons déjà un PR pour diff images

C'est vrai, mais cela ne couvre pas l'aperçu du balayage ou de la pelure d'oignon, uniquement côte à côte. De plus, je ne pense pas que cela couvre les fichiers PDF. Nous utilisons Gitea ici pour le développement de matériel graphique (y compris des manuels et des brochures), et un bon diff visuel pour les PDF changerait la vie.

J'ai quelques idées que je veux juste lancer là-bas :smile_cat:

1. Utilisez Cloud KSM pour chiffrer/déchiffrer n'importe quel secret de manière transparente. Cela protégera contre DB piraté et exposé. L'idée est que nous pouvons utiliser un type personnalisé avec des méthodes de codage/décodage XORM pour crypter les données secrètes avant d'écrire dans la base de données. Nous avons fait un exemple de démo ici : https://github.com/gomodules/ksm-xorm

2. Support OIDC : Renvoyez id_token en plus du jeton oauth2 lorsque vous êtes connecté via Gitea

3. Le profil utilisateur Gitea peut afficher le profil de l'utilisateur sur n'importe quel référentiel Git vérifié. Exemple : l'utilisateur peut épingler les dépôts Github/Gitlab/BitBuket/Gitea. L'idée est que les utilisateurs ne peuvent pas non plus ignorer les autres. Alors, gitea peut-il être le seul profil utilisateur global ?

4. Prise en charge de domaine personnalisé pour les dépôts (go)

5. Compatibilité complète avec Github (j'ai vu du travail sur ce front, je ne sais pas combien est déjà fait.)

6. Intégration facultative du serveur de langue. Quelque chose comme Sourcegraph comme la navigation intégrée dans l'interface utilisateur.

J'aimerais contribuer à 1 & 2 en peu de temps.

Peut-être pouvons-nous afficher les différences sous forme d'arborescence de dossiers et de fichiers qui ont changé - comme dans BitBucket, au lieu d'une énorme page avec tous les changements. Ce serait beaucoup, beaucoup plus lisible.

Peut-être une option pour agréger les notifications sur tous les référentiels par jour ou par semaine.
Un peu comme un résumé des activités de la semaine dernière.

Ajoutez la possibilité de définir des webhooks personnalisés via des modèles personnalisés et un pool de variables standard.

Pas une évolution de Gitea mais un side project qui serait utile : #7853

Parité des fonctionnalités avec github !

Ou, à tout le moins, une liste à jour sur le wiki, qui montre toutes les fonctionnalités dont nous avons encore besoin avant d'atteindre la parité. Ce serait un bon moyen de structurer les futurs efforts de développement.

@lonix1 jetez un œil à https://docs.gitea.io/en-us/comparison/ pour cette liste

@kolaente a l' air d'avoir presque toutes les coches ! Oui!

Je suis très nouveau ici, mais aussi un codeur volontaire ; J'adorerais si gitea prend en charge les points essentiels. C'est l'un des plus gros trous pour mon utilisation. Assez facilement contourné, mais je préférerais simplement avoir un système essentiel en place.

Je pense que le problème pour les points essentiels serait https://github.com/go-gitea/gitea/issues/693 (lien car il ne semble pas encore être référencé à partir d'ici).

Ajoutez également la Help documentation, accessible via le lien Help . La source initiale de cette documentation peut provenir de l' aide GitHub , avec des modifications spécifiques à Gitea.

L' aide de

1. Création de problèmes par e-mail (voir service desk GitLab).

Si plus de personnes commencent à adopter l'auto-hébergement pour partager leurs projets open source, il doit y avoir un moyen pour les utilisateurs non enregistrés de soumettre des problèmes sans avoir à créer un compte sur chaque instance (la plupart des gens sont extrêmement peu susceptibles de s'inscrire pour un bogue rapport).

1. Quelque chose qui s'apparente à AutoDevOps de GitLab. Cela signifie la possibilité de définir un travail CI par défaut lorsqu'aucun fichier yaml CI ne se trouve dans le référentiel.

2a. Onglet et authentification de l'interface utilisateur du registre de conteneurs.

1. Bots
2. GPG pour les commits Web
3. Possibilité de bloquer les fusions en fonction des conditions
4. Possibilité de créer un fichier dans l'interface utilisateur Web (y compris dans un référentiel vierge vierge)
5. Gérer les extraits attachés au dépôt via l'interface utilisateur (voir GitLab)
6. Prise en charge du protocole Git v2
7. Option Web IDE améliorée
8. Intégration de Kubernetes (via le plugin UI à la GitLab)
9. Ajouter un délai de 400 ms avant qu'une info-bulle ne s'affiche au survol
10. Meilleure intégration CI (afficher les pipelines, prise en charge de Concourse, etc.)
11. Affiner l'interface utilisateur
12. Appliquer 2FA
13. Verrouillage de fichiers
14. Fermeture automatique des problèmes liés avec la fusion des relations publiques.

Une sorte de système de plugin / extension.

La plupart des suggestions sont bonnes, mais elles créeront des problèmes dans la base de code principale.

Il serait préférable d'avoir des plugins officiels (et non officiels). Cela signifierait également que les auteurs de plugins pourraient publier plus fréquemment.

@lonix1 Eh bien, les hooks git, les webhooks et l'API Swagger peuvent être considérés comme des points de connexion de plugin. Je suis pour plus de support de plugin, mais énoncer une liste avec des détails pourrait aider. Par exemple, j'aimerais prendre en charge un équivalent en ligne de commande des webhooks.

@guillep2k Par exemple toutes les fonctionnalités de gestion de projet décrites ci-dessus. Ceux-ci seraient très utiles - mais ils touchent probablement tellement de parties de la base de code que 1) ils pourraient causer des problèmes même pour ceux qui n'utilisent pas ces fonctionnalités, et 2) à cause de cela, un tel développement est très lent car les responsables de fusionner de nouvelles fonctionnalités savent que ce scénario est possible, ils sont donc prudents.

Si ces nouvelles fonctionnalités pouvaient être publiées séparément, elles pourraient être essayées par des utilisateurs volontaires avant d'être fusionnées dans la branche principale.

Et il y a d'autres exemples de ce genre de grandes nouvelles fonctionnalités, faites simplement défiler vers le haut.

@brandonkal La signature GPG des commits générés automatiquement est désormais possible avec la fusion de #7631

Je suppose que la feuille de route devrait être divisée en ces quatre catégories (j'ai ajouté quelques exemples de problèmes - il devrait être évident qu'elle est loin d'être complète :wink:):

Fonctionnalité de base

Il y a encore des _fonctions de base_ qui ne fonctionnent pas correctement.
Par exemple:

• il a toujours besoin d'une bonne solution de recherche comme mentionné dans des problèmes tels que #5694 #5277 #3448, #2967, #2434, #8366, #8386 et #7825
• la visionneuse PDF est cassée
• la visionneuse SVG est cassée
• il semble qu'il y ait des dépendances non libres utilisées

Sécurité

Il y a aussi quelques problèmes de sécurité :

• [ ] [l'image Docker fonctionne toujours en tant que root] (https://github.com/go-gitea/gitea/issues/1190) bien que le guide Docker soit très clair à ce sujet et qu'il n'y ait aucune raison d'utiliser le root user (vous pouvez quand même remapper les ports à l'extérieur)
• [ ] [l'application de la 2FA n'est toujours pas possible](https://github.com/go-gitea/gitea/issues/880)
• [ ] [Activer la configuration d'en-têtes CSP plus stricts en supprimant les styles en ligne](https://github.com/go-gitea/gitea/issues/305)
• [ ] [il n'y a pas de vérification pour savoir si quelqu'un est autorisé à accéder aux pièces jointes](https://github.com/go-gitea/gitea/issues/7908)

L'intégration

Je suppose que l'intégration avec d'autres applications/services est une bonne chose en général.
Parce que le développement de logiciels ne repose généralement pas sur un seul outil.
Et cela aidera probablement à convaincre certaines personnes d'utiliser Gitea sur leur lieu de travail.

Ces deux problèmes amélioreraient considérablement l'interopérabilité :

• [ ] intégrer automatiquement Drone CI/CD ( comme @BNolet proposé précédemment )
• [ ] [Intégration d'API pour les revues de relations publiques automatisées](https://github.com/go-gitea/gitea/issues/5733) via des outils comme Pronto
• [ ] [intégration facile avec un registre de conteneurs](https://github.com/go-gitea/gitea/issues/2316)
• [ ] une solution de webhook générique qui permet aux utilisateurs de configurer facilement des webhooks personnalisés ( comme proposé par @bkcsoft plus tôt )

De plus, des webhooks génériques éviteraient d'avoir d'autres personnes connaissant les rouages ​​de gitea. @guillep2k a eu l'idée merveilleuse qu'une intégration de "commande externe" pourrait être effectuée de la même manière que l'intégration de webhook générique .
:warning: Cela résoudrait probablement la plupart des problèmes sur ce que la plupart des personnes dans ce problème veulent comme "support de plugin" . Parce que cela permettrait d'appeler tout ce que les utilisateurs ont besoin d'appeler. Cependant, @lunny vient de mentionner que cela est pratiquement déjà possible via les crochets git. Je ne suis tout simplement pas sûr que ce soit vraiment la meilleure façon d'intégrer d'autres outils/plugins/services.

Fonctionnalités au top

De plus, il y a évidemment quelques fonctionnalités intéressantes dans les applications concurrentes (c'est-à-dire Git[Hub/Lab]) (la plupart d'entre elles sont probablement plutôt agréables à avoir) :

• [ ] [Retour PRs](https://github.com/go-gitea/gitea/issues/6375)
• [ ] [Diff amélioré pour les choses non textuelles comme mentionné par @arthur-bauer](https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [ ] [modifications des responsables](https://github.com/go-gitea/gitea/issues/717)
• [ ] [Problèmes confidentiels](https://github.com/go-gitea/gitea/issues/3217)
• [ ] afficher plus de détails sur le référentiel (c'est-à-dire la taille du référentiel , le graphique des contributeurs , la barre des langues )
• [ ] quelques améliorations du wiki (#823 #574)
• [ ] [ayant un diff comme BitBucket comme mentionné par @SignumPL](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (je ne le savais pas avant mais ça a l'air vraiment utile )
• [ ] [intégrer une fonctionnalité comme Octotree](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

Peut-être utiliser la base de données Oracle en option ? Si c'est possible techniquement.

@DemiusAcademius Si xorm prend mieux en charge Oracle, je pense que c'est possible.

De plus en plus de personnes commencent à utiliser Gitea, par exemple également à cause de la récente annonce du tracker GitLab. Mais GitHub/GitLab ont toujours l'effet réseau de leur côté.

La fédération serait un grand moteur pour améliorer la capacité de collaboration entre les utilisateurs de différentes instances Gitea et ainsi augmenter l'ensemble du réseau Gitea : #1612

La possibilité d'afficher des différences importantes dans l'interface utilisateur a été signalée comme un facteur limitant dans l'adoption de Gitea.
Billets qui y répondent : #7341 (fonctionnalité), #7495 (bogue du crash)

La possibilité d'afficher des différences importantes dans l'interface utilisateur a été signalée comme un facteur limitant dans l'adoption de Gitea.
Billets qui y répondent : #7341 (fonctionnalité), #7495 (bogue du crash)

C'est une limitation énorme. OMI, tout ce que @alexanderadam listé ci - n'est rien en comparaison de cela. Si je ne peux pas revoir de grandes différences en commentant en ligne dans le code, c'est un gros problème.

Avec la colère contre Microsoft et Github qui a provoqué la migration de nombreux projets et une forte demande de fédération - Gitlab a récemment proposé d'interdire les employés en Chine et en Russie, 2 des plus grands pays du monde en termes de masse terrestre et d'économie. L'armée américaine s'est concentrée sur la Chine et la Russie (entre autres) pour affaiblir les barrières qu'elles posent à l'expansion/aux intérêts impériaux des États-Unis. La propagande et les incitations financières ont amené Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) et même Gitlab dans les industries de la guerre, de l'espionnage, de la propagande et de la surveillance dans un rôle offensif.

J'en parle pour remercier ceux qui travaillent sur des référentiels distants open source hautement disponibles avec peu de défauts pour les services d'entreprise et liés au Pentagone que nous utilisons et sur lesquels nous comptons toujours maintenant - et pour attirer votre attention sur le fait que des alternatives sont rapidement disparaître pour ceux qui souhaitent utiliser Internet et la technologie aussi loin de l'empire le plus puissant et le plus hostile de l'histoire.

Le sujet est peut-être suffisamment vaste pour qu'une section distincte du site Web officiel suive les progrès de cette fonctionnalité, ainsi qu'une campagne de collecte de fonds distincte pour répondre à cette demande. Inclure ForgeFed dans la collecte de fonds peut être bénéfique et équitable, vu leur travail jusqu'à présent. Cela fait 17 mois jour pour jour depuis que Microsoft a combattu Github, et j'espère que dans 17 mois nous pourrons utiliser Gitea fédéré, ou avoir des parties restantes de la valeur nette sur lesquelles s'appuyer.

S'il vous plaît, ne discutez pas de politique ici, restons-en au sujet - améliorer Gitea pour tout le monde

@lafriks Améliorer Gitea signifie définir une niche - quelque chose qui n'est pas satisfait par les produits de substitution. Le marketing est le processus de recherche d'opportunités externes, « politique » étant l'une des quatre principales catégories d'analyse marketing. Une marque avisée fait appel aux _valeurs_ des gens tout autant qu'elle offre des fonctionnalités, des spécifications et un prix. Il existe un attrait (« politique ») fondé sur des valeurs pour des alternatives comme Gitea, et ne pas le souligner et le maintenir serait un échec dans la compréhension de votre consommateur et de l'opportunité du marché.

« Politique » en tant que terme est devenu un cliché qui met fin à la pensée, éteignant la discussion sur le racisme, la violence et l'exploitation. Je suis simplement venu ici pour remercier les gens d'avoir continué à travailler sur des alternatives non associées aux camps de concentration américains, à la surveillance des filets d'entraînement et à d'autres intérêts impérialistes auxquels la majorité de notre industrie contribue activement. Si vous dites que ce ne sont pas des qualités que Gitea soutient, Je me suis trompé et je vais partir.

Note à @OKNoah

Marketing 101 pour un projet open source :

1. N'évoque pas les camps de concentration
2. Ne parle pas de politique
3. Perdre le chapeau en papier d'aluminium
4. N'utilisez pas de termes antiques tels que impérialisme
5. Connaissez l'avantage de votre produit. L'atout de Gitea est sa simplicité.

Si la transparence de GitLab.com vous offense, vous pouvez auto-héberger GitLab-FOSS. C'est un très bon produit tout-en-un. Mais si vous souhaitez une installation simple ou si vous avez besoin d'une utilisation de mémoire inférieure par rapport à GitLab ou GitHub Enterprise, Gitea est une bonne option pour les fonctionnalités Web de base.

Ce fil de discussion traite des fonctionnalités qui peuvent aider à combler cet écart sans compromettre la simplicité.

Mes 2 cents - Je pense que ce fil est devenu trop long, et il est temps d'ouvrir un nouveau numéro résumant toutes les idées déjà exprimées ici. Et ferme celui-ci.

Si vous dites que ce ne sont pas des qualités que Gitea soutient, je me suis trompé et je m'en vais.

Ce n'est pas ce qui est dit. Ce qui est dit, c'est que ce fil est l'endroit pour discuter des changements/améliorations qui peuvent être apportés à Gitea (en particulier techniques). Ces discussions sont plus que bienvenues, mais pas dans ce fil spécifique.

En tant que l'un des responsables, je verrouillerai ce fil de discussion, comme @XVilka l'a bien dit, nous avons sollicité de nombreux commentaires, et il devrait maintenant être évalué pour les prochaines étapes.

Nous pourrions changer le chemin vers la conformité FHS pour la v2. C'est déjà possible avec les drapeaux mais cela devrait être la valeur par défaut pour la v2.