Gitea: Обсуждение дорожной карты Gitea

Плагин (включая тему) для расширения gitea.

Можно ли добавить соответствующие пакеты ОС в процесс сборки? Я пытался собрать что-то для Fedora, но пакет go кажется беспорядочным. №31 вроде как говорит об этом, но все еще кажется открытым.

Мы используем ansible для развертывания tarball в системе Debian, это не очень удобно, но работает. Было бы неплохо создать репозиторий для наиболее распространенных дистрибутивов, но его необходимо создать и поддерживать.

Несколько предложений:

• Возможность автоматической интеграции Drone CI / CD в Gitea в процессе сборки.
• Дополнительные возможности настройки администрирования сайта из пользовательского интерфейса Gitea после установки. Например, я хотел бы иметь возможность изменять содержимое _Service Configuration_ на странице _Configuration_.
• Возможность скрыть пользователя от страницы исследования.

Федеративные запросы на вытягивание / проблемы / вилки

Федеративные запросы на вытягивание / проблемы / вилки

Возможно, он не является федеративным в смысле слова Fediverse (ActivityPub, OStatus, diaspora * и т. Д.), Но я хотел бы иметь возможность взаимодействовать с удаленными экземплярами из своего собственного, реализованного любым способом, который лучше всего подходит для проекта.

Также было бы здорово иметь команды и организации, состоящие из пользователей из нескольких экземпляров, хотя это, вероятно, будет невероятно сложно реализовать.

Два предложения от точки зрения конечного пользователя с минимальными навыками программирования, который пытается помочь проектам с открытым исходным кодом, которые я использую, сообщая об ошибках и оставляя отзывы по UX:
1) Помогите стандартизировать ForgeFed! Мне бы хотелось, чтобы UX регистрации ошибок в экземпляре Gitea (и других кузниц кода, поддерживаемых сообществом) был похож на один огромный децентрализованный GH.
2) Сделайте каждую часть проекта репозиторием Git, чтобы проблемы, вики и т. Д. Можно было легко извлечь, разветвить, отправить или разветвить. GL и sr.ht делают это по крайней мере с некоторыми из своих компонентов. Это не только полезно, но и может помочь с пунктом 1)

Возможность отвечать на билеты по электронной почте станет большим шагом вперед для удобства использования.

Разрешить редактирование всей конфигурации из пользовательского интерфейса (и, возможно, изменить формат файла конфигурации во время процесса)

Возможно, сохранить большую часть конфигурации в базе данных и предоставить для нее правильный cli и api

@sapk @tboerger Я бы сказал, что мы должны переключиться на viper для конфигурации, чтобы мы могли избавиться от ini (и некоторых ошибок, которые у нас были с ним) и получить такие вещи, как перезагрузка конфигурации во время работы Gitea и правильные переменные env .

Я бы хотел заняться этим, но не уверен, что найду время в ближайшем будущем.

Я тоже за Viper. Я пытался это сделать 2 года назад, но не успел закончить ... но я могу попробовать еще раз :)

Я за получение более минимального файла конфигурации ... Многие из этих настроек не нужно устанавливать через статический файл конфигурации, их можно легко добавить в базу данных и кэшировать по соображениям производительности.

Я думаю, что мы могли бы сначала добавить таблицу конфигурации базы данных и переместить туда большинство изменяемых элементов конфигурации из файла ini, оставив только те элементы, которые необходимо перезагрузить.

@lunny и все

Модульная система звучит отлично. Я считаю, что есть много людей, желающих добавить новые функции в gitea.

@belliash @sapk Плагины / модули IMO не могут быть реализованы эффективно без полного рефакторинга пакета моделей и добавления дополнительной абстракции. Я протестировал несколько технологий, например, встроенную поддержку плагинов Go.

Результатом стали гигантские двоичные файлы, которые сильно зависели от двоичного файла Gitea.

Я думаю, что улучшение поддержки веб-перехватчиков и добавление пользовательских страниц с помощью веб-перехватчиков более реалистично, поскольку у нас уже есть довольно зрелый API, который можно использовать для операций с базой данных.

@jonasfranz Я бы очень поддержал модели рефакторинга, чтобы удалить множество их зависимостей.

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

выявляет 98 (!) прямых импортных операций. 50 из которых не являются основными.

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

выявляет 437 (!!) транзитивных зависимостей. (304 из них не являются основными)

Взгляните на исходники дронов, там у нас много подключаемого материала, основанного на веб-хуках.

Кроме того, имеет смысл такая модель плагина, как packer, система плагинов на основе grpc.

@tboerger Не могли бы вы привести пример подключаемого материала дрона? Вы имеете в виду систему плагинов, основанную на образах докеров?

Я говорю о расширениях для конфигов, секретов и так далее, интерфейсы должны быть определены на https://github.com/drone/drone/tree/master/plugin

Я согласен с вами, следующим большим шагом Gitea должна стать система плагинов. Я тоже думаю об этом в наши дни. Я попробую систему плагинов.

Я думаю, что он должен быть похож на систему плагинов дрона, но иметь больше. Мы должны позволить плагину иметь пользовательский интерфейс и автоматически входить в систему с помощью Gitea OAuth2. И у нас должна быть какая-то политика безопасности для плагинов. и так далее.

Я хочу поделиться сравнительной таблицей, которую мы составили примерно в 2016 году, чтобы решить, какую хостинговую платформу выбрать для Open Source Geospatial Foundation. В этой таблице мы перечислили важные для нас функции. Gitea находится в одной из колонок:

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

Вы увидите, что важная функция, которая отсутствовала в 2016 году, все еще отсутствует сегодня: ответ по электронной почте (комментарий / ответ) --- некоторые другие были реализованы на сегодняшний день.

Инструмент @strk для migrate from github и Comments on diff lines готов.

Требуется настройка почтового шаблона
См. № 6037

Так что уже есть возможность немного настроить шаблон - тема - единственное, чего, по-моему, у нас нет.

Однако на самом деле нам следует включить i18n для электронной почты и сообщений git serv hook.

Требуется отменить запрос на перенос.
См. №6375

Полная поддержка тегов в UI. Создавать, назначать, изменять, удалять и т. Д. Мне очень не хватает этой функции.

Я поддерживаю конфигурацию в базе данных (с помощью cli или api для ее настройки, например, создание пользователя и аутентификацию ldap и т. Д.) И систему плагинов.
Эти двое должны продвинуть gitea на большой шаг вперед.

LFS

• [x] Нам нужен какой-то способ управления файлами LFS в репозитории - в настоящее время они полностью непрозрачны. # 7199 - это попытка предоставить это - но для эффективности, вероятно, потребуется ...
  
  
  
  • [] Фильтр Блума для поиска по BLOB-объекту - было бы очень хорошо иметь какой-нибудь немного эффективный способ найти фиксацию и путь к дереву, который привел к появлению BLOB-объекта.
  
  
• [] В настоящее время не существует надежного способа перезапуска загрузки в LFS - поэтому очень большие загрузки могут постоянно терпеть неудачу. Реализуйте tus.io согласно # 1723
• [] Мы должны предоставить возможность просто использовать .gitattributes для определения, является ли файл указателем LFS, а не просто предполагать, что любой файл, который выглядит как указатель, является указателем. Хотя это, скорее всего, сделает функциональность в # 7199 очень сложной ...
• [] Файлы LFS должны быть доступны для просмотра в режиме просмотра различий.

Закалка

Завершение работы и начало создания действительно кластеризованной Gitea

• [] Нам нужно усилить реакцию Gitea на завершение работы.
  
  
  
  • [x] Это означает постепенное отключение прослушивающих подключений, особенно встроенного SSH, что в настоящее время может вызвать повреждение репозиториев git из-за внезапного завершения работы. # 7274 - это попытка исправить это.
  
  
  • [], но также это означает, что уведомления, такие как задания, должны быть сериализуемыми - например, очереди индексации должны проходить через очереди на диске или в базе данных, аналогично почтовые очереди и т. д. У нас уже есть некоторые из них, но эти очереди не завершаются корректно.
  
  
• [] Как следствие вышесказанного, мы должны отделить действие индексации от поиска. В любом случае этого требует постепенное завершение работы, но это часть шага к кластеризации. Я не уверен, какую архитектуру мы должны выбрать, но есть несколько вариантов - выделить индексатор в отдельный процесс и сделать индекс Gitea доступным только для чтения, или экспортировать всю индексацию.

Различие и чтение данных произвольной длины в память

• [] Дифференциальный код требует рефакторинга - он хрупкий, считывает все различия в память и требует, чтобы браузер проанализировал огромные различия, прежде чем пользователь сможет ответить. Для этого требуются изменения как пользовательского интерфейса, так и сервера - по-видимому, правильным методом для этого является бесконечная прокрутка с поддержкой Ajax. В настоящее время достаточно зловещая большая разница может вывести из строя и сервер, и браузер.
• [] Наша архитектура diff в настоящее время загрязняет базовый репозиторий предварительно объединенными ветвями и объектами.
• [] В общем, мы ДОЛЖНЫ прекратить просто чтение данных произвольной длины в память. Если есть место, где это может понадобиться браузеру - мы должны ограничить то, что мы читаем, а затем использовать либо технику бесконечной прокрутки, либо полную ссылку с рендерингом браузера или рендерингом в конвейере, чтобы гарантировать, что это не буферизуется полностью в памяти. Даже относительно новый код все еще страдает от этой проблемы.
• [] (Если мы запускаем процесс git, который может возвращать произвольно длинные данные, мы должны стараться полностью избегать их чтения непосредственно в буфер stdout, но делать больше конвейеров go-рутины.)

Объединить

• [] Мы должны реорганизовать слияние, чтобы полностью использовать индекс git, так как в настоящее время мы выполняем разреженную проверку для слияния - в основном потому, что слияние git откроется в https://git-scm.com/docs/git-merge-one-file, чтобы обрабатывать слияния без перемотки вперед. Это заставляет создавать на сервере полу-произвольные пути, которые не нужны и зависят от факторов кодировки / файловой системы. В этом нет необходимости - мы можем выполнять эти слияния с временными файлами, хешированием и добавлением в индекс напрямую.

Места побега и хранилища

• [] Мы должны везде проверять, нет ли побега. Унаследованный код Gogs в целом плохо экранировался и был причиной множества проблем с безопасностью.
• [] Предположение, что имя пользователя и имена репозитория не нуждаются в экранировании, вынуждает нас принять архитектурное решение, которое нам не нужно. Он даже не защитил нас должным образом от сигнатур git, следовательно, # 5774.
• [] Хотя пользователям приятно, когда расположение базового репозитория совпадает с расположением файловой системы - например, $GITEA_ROOT/owner/reponame это плохое архитектурное решение IMHO и приводит к предположениям пользователей, что наши репозитории могут использоваться git на сервере без Дальше думал - ОНИ НЕ ДОЛЖНЫ. Мы должны перейти на $GITEA_ROOT/repository-$ID , возможно, сегментированный. (Это позволит удалить множество вызовов repo.MustOwner() или repo.GetOwner() )
  
  
  
  • [] Как только мы перейдем к вышеуказанному и уйдем от всего должным образом, мы сможем ослабить ограничения на имена пользователей и имена репозиториев - хотя об этом нужно будет тщательно продумать, чтобы убедиться, что мы делаем это таким образом, который не позволяет подделка через проблемы, похожие на # 5774.
  
  
• [x] Мы должны обеспечить выполнение серверных процессов git с достаточной средой Gitea - есть постоянные пользователи, которые пытаются использовать репозитории Gitea на сервере, не используя Gitea, поэтому затем жалуются, что Gitea не обновляется и т. д. # 6961 - это необходимый шаг к этому, и после слияния мы просто меняем https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72, чтобы принудительно установить SSH_ORIGINAL_COMM, чтобы принудительно установить SSH_ORIGINAL_COMM стандартного окружения.
• [] Мы должны быть в состоянии справиться с подключенными репозиториями NO_EXEC - и на самом деле мы, вероятно, должны рекомендовать это. Это, вероятно, на самом деле не сложно сделать - просто измените переменную .git/config или центральную переменную .gitconfig core.hooksPath и подумайте, где в противном случае мы будем размещать хуки.
• [] Мы в основном сохраняем строки кода непосредственно в базе данных для комментариев - что не работает, если сохраняемые данные не в UTF-8. Это означает, что вы просто не можете комментировать код, отличный от UTF8.

API / SDK

• [] Сумасшедший объем работы, который нам нужно проделать для создания API, когда мы прилагаем все усилия, чтобы иметь чванство. Мы должны просто автоматически сгенерировать это из чванства или автоматически сгенерировать как можно больше
• [] У нас нет возможности протестировать фиксированную версию API на нашей разрабатываемой Gitea, поэтому мы не можем сказать, когда вносим критические изменения.
• [] Мы должны иметь возможность использовать автоматически сгенерированный API / SDK для создания простых тестовых программ.

Тестирование

• [] В настоящее время мы запускаем наши модульные тесты на уровне TRACE - это ограничивает нашу способность добавлять правильную трассировку к вещам. Начиная с https://gitea.com/gitea/log/pulls/3 и если мы вернемся в Gitea, мы сможем изменить это из нашего make-файла.
• [] Необходимо больше модульных тестов и подумать, действительно ли некоторые из интеграционных тестов являются модульными и наоборот. например https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [] Нам нужно больше интеграционных тестов, которые попытаются пройти через пользовательские истории. То есть - пользователь входит в систему, делает X, затем происходит Y и Z. Это нормально тестировать изолированно, например. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go, но на самом деле он не интегрирован, и он пропускает тестирование того, что испытывает пользователь. Я все время говорю об этом, но больше тестов должно выглядеть так: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go и https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go, которые на самом деле проверяют, правильно ли интегрируется функция.
• [x] Наш режим тестирования занимает слишком много времени - в настоящее время CI запускается 30-40 минут! Мы должны запускать их параллельно.
• [] Нет простого способа создать тесты миграции.

Архитектура пакета Go

Модели

• [] code.gitea.io/gitea/models зависит от слишком многих вещей, которые необходимо остановить.
• [] models.x необходимо уничтожить. Ужасное архитектурное решение.
• [] Для слишком многих моделей слишком легко вызвать разыменование нулевого указателя, потому что вы не знаете, в каком состоянии он находится. Можем ли мы использовать здесь систему набора текста лучше?
• [x] Мы должны просто вставить OwnerName в таблицу репозитория, поскольку каждый раз, когда мы получаем репозиторий, мы должны идти и получать владельца. Это глупо и пустая трата времени. Хранилища не очень часто меняют владельца, поэтому затраты на обслуживание не являются значительными.
• [] Слишком много вещей все еще сделано в моделях, и нужно убрать больше.
• [] Возможно, имеет смысл разделить модели на основные и непрофильные.

Модули

• [x] По сути, существует два типа модулей: те, которые зависят от моделей, и те, от которых зависят модели. Разделим их, можно было бы назвать услугами.

Макарон

• [] Думаю, нам следует серьезно отнестись к переходу на джин, предложенному @lunny.
• [] Наша кодовая база забрызгана зависимостями от Macaron, этого не должно быть.

Параметр

• [] Зависит и от макарон (!)
• [] Тесно связана с go-ini, еще одной зависимостью, от которой мы должны подумать, отключившись от нее.

Интернационализация

• [] Электронная почта не интернационализирована
• [] Сообщения Git не интернационализированы
• [] Сообщения об ошибках не интернационализированы
• [] Мы должны автоматизировать удаление документации на нашем веб-сайте hugo, чтобы ее можно было интернационализировать с помощью CrowdIn.
• [] Странно, что у нас есть языки, использующие строчные формы, например, français, español в списках выбора языков - это означает начало предложения на каждом из этих языков, поэтому AFAICS они должны быть заглавными. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • английский
  
  
  • Français
  
  
  • Español
  
  

Дамп и восстановление Gitea

• [] Дамп Gitea не работает при преобразовании между вариантами SQL
• [] У нас нет команды восстановления

Что касается пользовательского интерфейса, я бы предложил предоставить два пользовательских интерфейса:

• один простой HTML (похожий на текущий без js)
• полный JS, который полагается только на вызов API. Это заставит переосмыслить несколько API, но также позволит больше взаимодействовать с другими внешними приложениями.

• думаю, нам следует серьезно отнестись к переходу на джин, предложенному @lunny

Я бы предложил го-чи вместо джина.

• Мы должны автоматизировать удаление документации нашего веб-сайта hugo, чтобы ее можно было интернационализировать с помощью CrowdIn.

ИМХО сайт / документы переводить вообще не надо, все равно всегда устарело ...

ИМХО сайт / документы переводить вообще не надо, все равно всегда устарело ...

Но с толпой его устаревание уведомит людей и сделает текущие переводы недействительными.

Можно ли добавить соответствующие пакеты ОС в процесс сборки? я

Возможно, пакеты в стиле PPA, контролируемые и поддерживаемые разработчиками GItea, были бы хорошей идеей, но я не поклонник способа управления версиями в стиле Debian "замораживания и обратного переноса исправлений безопасности" для быстро меняющихся проектов (таких как GItea).

Я все еще хотел бы https://github.com/go-gitea/gitea/issues/3840.
Думаю, это можно реализовать с обратной совместимостью.
Но это станет ясно только после завершения миграции новой библиотеки маршрутизации.
Предварительная базовая очистка / рефакторинг также упростит задачу.

Я все еще хотел бы # 3840.
Думаю, это можно реализовать с обратной совместимостью.
Но это станет ясно только после завершения миграции новой библиотеки маршрутизации.
Предварительная базовая очистка / рефакторинг также упростит задачу.

В этом случае возможно, что вы потеряете поддержку Drone, поскольку в настоящее время она также не реализована для Gitlab.

Я все еще хотел бы # 3840.
Думаю, это можно реализовать с обратной совместимостью.
Но это станет ясно только после завершения миграции новой библиотеки маршрутизации.
Предварительная базовая очистка / рефакторинг также упростит задачу.

Нам, вероятно, не нужна эта групповая функция, чтобы влиять на URL-адреса репозитория, мы могли бы просто сделать папки, которые репозиторий можно было бы отображать, но сохранить URL-адреса репозитория такими же, как сейчас

@tboerger
Я думал, что URL-адрес может остаться прежним, если репо не вложено в группу / каталог.
URL-адреса необходимо «обновить» только в том случае, если репо использует функцию группы / каталога.
Но да, репозитории с новыми URL-адресами, вероятно, не могли иметь поддержку Drone из коробки.

@lafriks
Это звучит как хорошая идея. Мой сценарий использования этой функции заключается в размещении модулей Git или подпроектов проектов Repo. Так что я не уверен, что это касается этого случая.

Не стоит беспокоиться. Я не хочу делать такие масштабные и, возможно, критические изменения.

В этой проблеме есть много хороших идей, и мы должны сохранить их и решить.
Однако когда и как выбирать? Это обсуждение может продолжаться вечно.

Я бы посоветовал либо владельцу выбрать темы, либо проголосовать между ними и участниками.
Что вы думаете?

@DblK Верно. Но я думаю, что мы сможем это сделать после перехода на gitea.com. В настоящее время нам нужно больше отзывов от пользователей.

• Mercurial поддержка
• лучшая сортировка и фильтрация по PR и проблемам

• Mercurial поддержка

Пожалуйста нет. Не зря он называется "git" ea.
Я понимаю желание расширить возможности, но
раздувание не за горами ...

ртутный импорт был бы альтернативой

26 июля 2019 г., 13:52:50 по всемирному координированному времени Сандро Сантилли [email protected] написал:

• Mercurial поддержка

Пожалуйста нет. Не зря он называется "git" ea.
Я понимаю желание расширить возможности, но
раздувание не за горами ...

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Федеративные запросы на вытягивание / проблемы / вилки

Возможно, он не является федеративным в смысле слова Fediverse (ActivityPub, OStatus, diaspora * и т. Д.), Но я хотел бы иметь возможность взаимодействовать с удаленными экземплярами из своего собственного, реализованного любым способом, который лучше всего подходит для проекта.

Об этом уже говорилось в # 1612. ForgeFed собирает интересные идеи по внедрению федерации в кузницы кода, такие как Gitea. Было бы здорово, если бы это стало следующей важной особенностью Gitea!

Мне бы очень понравился инструмент визуального сравнения графических файлов (JPEG, PNG, а также PDF), аналогичный тому, что предлагает Github .

У нас уже есть PR по разным изображениям

У нас уже есть PR по разным изображениям

Верно, но это не касается смахивания или предварительного просмотра кожи лука, только бок о бок. Кроме того, я не думаю, что это касается файлов PDF. Здесь мы используем Gitea для разработки графических материалов (включая руководства и брошюры), и хороший визуальный эффект для PDF-файлов изменит жизнь.

У меня есть несколько идей, которые я просто хочу выкинуть: smile_cat:

1. Используйте Cloud KSM для прозрачного шифрования / дешифрования любого секрета. Это защитит от взлома и разоблачения БД. Идея состоит в том, что мы можем использовать настраиваемый тип с методами кодирования / декодирования XORM для шифрования секретных данных перед записью в БД. Здесь мы сделали демонстрационный пример: https://github.com/gomodules/ksm-xorm

2. Поддержка OIDC: возврат id_token в дополнение к токену oauth2 при входе в систему через Gitea

3. Профиль пользователя Gitea может отображать профиль пользователя в любом проверенном репозитории Git. Пример: пользователь может закрепить репозитории Github / Gitlab / BitBuket / Gitea. Идея в том, что пользователи не могут игнорировать и другие. Итак, может ли gitea быть одним глобальным профилем пользователя?

4. Поддержка пользовательского домена для репозиториев (go)

5. Полная совместимость с Github (я видел некоторые работы в этом направлении, я не знаю, сколько уже сделано).

6. Дополнительная интеграция языкового сервера. Что-то вроде Sourcegraph, вроде навигации, встроенной в пользовательский интерфейс.

Я хотел бы внести свой вклад в 1 и 2 в кратчайшие сроки.

Возможно, мы сможем показать разницу в виде дерева папок и файлов, которые изменились - как в BitBucket, вместо одной огромной страницы со всеми изменениями в ней. Это было бы намного более читабельно.

Возможно, вариант агрегировать уведомления во всех репозиториях за день или за неделю.
Что-то вроде краткого обзора деятельности за последние недели.

Добавьте возможность определять настраиваемые веб-перехватчики с помощью настраиваемых шаблонов и пула стандартных переменных.

Не эволюция Gitea, а полезный побочный проект: # 7853

Паритет возможностей с github!

Или, по крайней мере, актуальный список в вики, который показывает все те функции, которые нам еще нужны, прежде чем мы достигнем паритета. Это было бы хорошим способом структурировать будущие усилия по развитию.

@ lonix1 посмотрите https://docs.gitea.io/en-us/comparison/ для этого списка

@kolaente похоже, что у нас почти все галочки! Ага!

Я здесь совсем новичок, но тоже готовый кодировать; Мне бы очень понравилось, если бы gitea поддерживала gists. Это одна из самых больших дыр в моем использовании. Достаточно легко обойти, но я бы предпочел просто иметь систему сути.

Я думаю, что проблема для gists будет https://github.com/go-gitea/gitea/issues/693 (ссылка, поскольку, похоже, здесь еще нет ссылки).

Добавьте также Help документацию, доступ к которой можно получить по ссылке Help . Первоначальный источник этой документации может быть из справки GitHub с изменениями, специфичными для Gitea.

@bagasme help нельзя брать с github, это было бы нарушением авторских прав. Кому-то придется писать Gitea help с нуля

1. Создание задач по электронной почте (см. Службу поддержки GitLab).

Если все больше людей начнут внедрять самостоятельный хостинг для обмена своими проектами с открытым исходным кодом, должен быть способ для незарегистрированных пользователей отправлять проблемы без необходимости создавать учетную запись в каждом экземпляре (большинство людей крайне маловероятно, чтобы зарегистрироваться из-за ошибки. отчет).

1. Что-то вроде AutoDevOps GitLab. Это означает возможность определить задание CI по умолчанию, когда в репозитории нет yaml-файла CI.

2а. Вкладка пользовательского интерфейса реестра контейнера и auth.

1. Боты
2. GPG для веб-коммитов
3. Возможность блокировать слияния на основе условий
4. Возможность создания файла в веб-интерфейсе (в том числе в пустом репозитории)
5. Управляйте сниппетами, прикрепленными к репо, через пользовательский интерфейс (см. GitLab)
6. Поддержка протокола Git v2
7. Улучшенная опция Web IDE
8. Интеграция Kubernetes (через плагин UI а-ля GitLab)
9. Добавьте задержку 400 мс перед отображением всплывающей подсказки при наведении курсора
10. Лучшая интеграция CI (показывать конвейеры, поддержка Concourse и т. Д.)
11. Усовершенствовать пользовательский интерфейс
12. Принудительное использование двухфакторной аутентификации
13. Блокировка файлов
14. Автоматическое закрытие связанных проблем с объединением PR.

Какая-то система плагинов / расширений.

Большинство предложений хороши, но они создадут проблемы в основной кодовой базе.

Было бы лучше иметь официальные (и неофициальные) плагины. Это также означало бы, что авторы плагинов могли бы выпускать их чаще.

@ lonix1 Ну, git hooks, webhooks и Swagger API можно считать точками подключения плагинов. Я за дополнительную поддержку плагинов, но список с подробностями может помочь. Например, мне нужна поддержка эквивалента веб-перехватчиков в командной строке.

@ guillep2k Например, все функции управления проектами, описанные выше. Это было бы очень полезно, но они, вероятно, затрагивают так много частей кодовой базы, что 1) они могут вызвать проблемы даже у тех, кто не использует эти функции, и 2) из-за этого такая разработка идет очень медленно, потому что те, кто отвечает за слияние новых функций знает, что этот сценарий возможен, поэтому они осторожны.

Если бы эти новые функции можно было выпускать отдельно, их могли бы опробовать желающие пользователи перед тем, как объединить их в основную ветку.

Есть и другие примеры таких больших новых функций, просто прокрутите вверх.

@brandonkal Подписание GPG автоматически созданных

Думаю, дорожную карту следует разделить на эти четыре категории (я добавил несколько примеров проблем - должно быть очевидно, что она далека от завершения: wink :):

Базовая функциональность

Есть еще некоторые _базовые функции_, которые не работают должным образом.
Например:

• ему по-прежнему требуется хорошее решение для поиска, как упоминалось в таких проблемах, как # 5694 # 5277 # 3448, # 2967, # 2434, # 8366, # 8386 и # 7825.
• просмотрщик PDF сломан
• просмотрщик SVG сломан
• похоже, что используются несвободные зависимости

Безопасность

Также есть некоторые проблемы с безопасностью:

• [] [образ Docker по-прежнему работает от имени пользователя root] (https://github.com/go-gitea/gitea/issues/1190), хотя в руководстве Docker об этом очень четко сказано, и нет причин использовать root user (вы все равно можете переназначить порты снаружи)
• [] [принудительное использование двухфакторной аутентификации по-прежнему невозможно] (https://github.com/go-gitea/gitea/issues/880)
• [] [Включите настройку более строгих заголовков CSP, удалив встроенные стили] (https://github.com/go-gitea/gitea/issues/305)
• [] [нет проверки, разрешен ли кому-либо доступ к вложениям] (https://github.com/go-gitea/gitea/issues/7908)

Интеграция

Думаю, интеграция с другими приложениями / сервисами в целом - это хорошо.
Потому что разработка программного обеспечения обычно не полагается только на один инструмент.
И это, вероятно, поможет убедить некоторых людей использовать Gitea на своем рабочем месте.

Эти две проблемы могут значительно улучшить взаимодействие:

• [] автоматически интегрирует Drone CI / CD ( как @BNolet, предложенный ранее )
• [] [Интеграция API для автоматических обзоров PR] (https://github.com/go-gitea/gitea/issues/5733) с помощью таких инструментов, как Pronto
• [] [простая интеграция с реестром контейнеров] (https://github.com/go-gitea/gitea/issues/2316)
• [] универсальное решение для веб-перехватчиков, которое позволяет пользователям легко настраивать собственные перехватчики ( например, предложенное ранее @bkcsoft )

Кроме того, общие веб-перехватчики позволят избежать необходимости того, чтобы другие люди знали внутреннее устройство gitea. @ guillep2k пришла в голову замечательная идея, что интеграция "внешней команды" может быть сделана аналогично общей интеграции webhook .
: warning: Это, вероятно, решило бы большинство проблем, связанных с тем, что большинство людей в этом выпуске хочет, как «поддержка плагинов» . Потому что это позволит вызывать все, что нужно для звонка пользователям. Однако @lunny только что упомянул, что это практически уже возможно с помощью хуков git. Я просто не совсем уверен, действительно ли это лучший способ интеграции других инструментов / плагинов / сервисов.

Лучшие функции

Кроме того, очевидно, что в конкурирующих приложениях (например, Git [Hub / Lab]) есть несколько хороших функций (большинство из них, вероятно, неплохо иметь):

• [] [Восстановить PR] (https://github.com/go-gitea/gitea/issues/6375)
• [] [Улучшено различие для нетекстовых вещей, как упомянуто @ arthur-bauer] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [] [изменения от сопровождающих] (https://github.com/go-gitea/gitea/issues/717)
• [] [Конфиденциальные вопросы] (https://github.com/go-gitea/gitea/issues/3217)
• [] показать дополнительную информацию о репозитории (например, размер репозитория , график участников , языковую панель )
• [] некоторые улучшения вики (# 823 # 574)
• [] [наличие различий, таких как BitBucket, как упомянуто @SignumPL] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (я не знал этого раньше, но выглядит действительно полезным )
• [] [интегрируйте такие функции, как Octotree] (https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

Можно ли использовать Oracle Database как вариант? Если это возможно технически.

@DemiusAcademius Если xorm лучше поддерживает оракул, я думаю, что это возможно.

Все больше и больше людей начинают использовать Gitea, например, это также вызвано недавним анонсом трекера GitLab. Но GitHub / GitLab по-прежнему имеют сетевой эффект на своей стороне.

Федерация станет важным фактором для улучшения возможности совместной работы пользователей разных экземпляров Gitea и, таким образом, увеличения всей сети Gitea: # 1612

Сообщается, что возможность отображать большие различия в пользовательском интерфейсе является ограничивающим фактором при внедрении Gitea.
Билеты на это: # 7341 (особенность), # 7495 (ошибка сбоя).

Сообщается, что возможность отображать большие различия в пользовательском интерфейсе является ограничивающим фактором при внедрении Gitea.
Билеты на это: # 7341 (особенность), # 7495 (ошибка сбоя).

Это огромное ограничение. ИМО, все перечисленное выше @alexanderadam меркнет по сравнению с этим. Если я не могу просматривать большие различия, добавляя встроенные комментарии в код, это большая проблема.

Без гнева на Microsoft и Github, который вызвал миграцию многих проектов и вызвал высокий спрос на федерацию - Gitlab недавно предложил запретить сотрудникам в Китае и России, 2 из крупнейших стран мира по суше и экономике. Американские военные переключили внимание на Китай и Россию (среди прочих), чтобы ослабить барьеры, которые они создают для имперской экспансии / интересов США. Пропаганда и финансовые стимулы привели Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) и даже Gitlab в отрасли войны, шпионажа, пропаганды и наблюдения в наступательной роли.

Я поднимаю это, чтобы поблагодарить тех, кто работает над высокодоступными удаленными репозиториями с открытым исходным кодом с небольшими недостатками в корпоративных и связанных с Пентагоном сервисах, которые мы используем и на которые до сих пор полагаемся, и чтобы обратить ваше внимание на быстрые альтернативы. исчезает для тех, кто желает использовать Интернет и технологии, так далеко от самой могущественной и враждебной империи в истории.

Возможно, эта тема достаточно велика для отдельного раздела официального сайта, чтобы отслеживать прогресс в этой функции, наряду с отдельной кампанией по сбору средств для удовлетворения этого спроса. Включение ForgeFed в сбор средств может быть полезным и справедливым, учитывая их работу на данный момент. Прошло 17 месяцев с тех пор, как Microsoft боролась с Github, и я надеюсь, что еще через 17 месяцев мы сможем использовать федеративную Gitea или нарастить оставшиеся части собственного капитала.

Пожалуйста, не обсуждайте здесь политику, давайте вернемся к теме - улучшение Gitea для всех

@lafriks Улучшение Gitea означает определение ниши - чего-то, чего не хватает товарами-заменителями. Маркетинг - это процесс поиска внешних возможностей, причем «политические» являются одной из четырех основных категорий маркетингового анализа. Мудрый бренд обращается к _значениям_ людей в той же мере, в какой они предоставляют функции, характеристики и цену. Существует ценностная («политическая») тяга к таким альтернативам, как Gitea, и неспособность подчеркнуть и поддерживать ее будет означать неспособность понять вашего потребителя и рыночные возможности.

Термин «политический» стал улавливающим мысли клише, заглушающим обсуждение расизма, насилия и эксплуатации. Я просто пришел сюда, чтобы поблагодарить людей за продолжающуюся работу над альтернативами, не связанными с концентрационными лагерями США, сетевым наблюдением и другими интересами империалистов, которым активно помогает большая часть нашей индустрии. Если вы говорите, что это не те качества, которые поддерживает Gitea, Я ошибся и уйду.

Примечание для @OKNoah

Маркетинг 101 для проекта с открытым исходным кодом:

1. Не поднимайте концентрационные лагеря
2. Не упоминайте политику
3. Потерять шляпу из фольги
4. Не используйте античные термины, такие как империализм.
5. Знайте преимущества своего продукта. Преимущество Gitea в простоте.

Если вас оскорбляет прозрачность GitLab.com, вы можете самостоятельно разместить GitLab-FOSS. Это очень хороший универсальный продукт. Но если вам нужна простая установка или требуется меньшее использование памяти по сравнению с GitLab или GitHub Enterprise, Gitea - хороший вариант для основных веб-функций.

Эта ветка посвящена обсуждению функций, которые могут помочь закрыть этот пробел без ущерба для простоты.

Мои 2 цента - я думаю, что эта ветка стала слишком длинной, и пришло время открыть новый выпуск, обобщающий все идеи, уже высказанные здесь. И закрой это.

Если вы говорите, что Гитеа не поддерживает эти качества, я вас неправильно понял и уйду.

Говорят не об этом. Говорят, что эта ветка - место для обсуждения того, какие изменения / улучшения в Gitea можно внести (особенно технические). Эти обсуждения более чем приветствуются, но не в этой конкретной ветке.

В качестве одного из потенциальных клиентов я буду блокировать эту ветку , поскольку

Мы могли бы изменить путь к соответствию FHS для v2. Это уже возможно с флагами, но это должно быть по умолчанию для v2.