Gitea: Предоставление релизов и пакетов deb/rpm через Bintray

Нам действительно нужен deb/rpm? Разве недостаточно просто образов докеров? Идк, докажи, что я не прав! :)

У дрона есть только образы докеров, верно?

Gogs использует packager.io, почему бы не использовать его повторно?

Потому что не все используют докер.

Packager.io поддерживает только версии lts, ​​кроме того, упаковка golang может быть выполнена намного проще, чем с накладными расходами Packager.io.

Хорошо, я недостаточно знаю о Go. Но иметь решение для Ubuntu 16.04 было бы здорово, так как https://github.com/gogits/gogs/pull/3617 не объединились :(

Чтобы предоставить пакеты для любой версии ubuntu/debian/любой, мы можем обернуть один и тот же двоичный файл в пакет и просто нужно настроить скрипт инициализации (sysvinit, systemd).

Можем ли мы объединить 16.04 packager.io PR и включить на нем gitea на данный момент?

Нужен и бинарник, и докер.

Можем ли мы объединить 16.04 packager.io PR и включить на нем gitea на данный момент?

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

Я также хотел бы бинарные выпуски - у меня нет настройки среды разработки для компиляции.

Кроме того, смогу ли я перейти на gitea с gogs? Я бы не хотел терять свои проблемы и т. д.

У нас будут бинарные версии и, надеюсь, также пакеты для основных дистрибутивов Linux. Вам не нужно ничего компилировать.

У нас также будут двоичные файлы для последней основной версии.

Вы сможете напрямую запускать gitea с базой данных Gogs. Если у нас есть изменения в базе данных, они автоматически переносятся.

Ооо звучит круто! тогда жду с нетерпением ☺

-- Starbeamrainbowlabs (keybase.io/sbrl)

https://packagecloud.io (OSS — 25 ГБ хранилища / 250 ГБ пропускной способности + CDN bintray.com 1 ТБ/м)

@tboerger https://packagecloud.io/docs#os_distro_version LTS и не-LTS deb/rpm/etc…
elementary OS / Raspbian / Ubuntu / Debian / SUSE Linux Enterprise Server / openSUSE / Fedora / LinuxMint / poky distro / Oracle Linux / Scientific Linux / Enterprise Linux (CentOS, RedHat, Amazon Linux)

@denji да, я знаю packagecloud, возможно, мы возьмем его, но нам нужен плагин для дрона :)

Этого не произойдет для 1.0.0, поэтому я перенесу его на 1.1.0.

Gogs уже предоставляет пакеты deb и rpm, так что будет очень жаль, если этого не произойдет для 1.0.0.

Смогу ли я без проблем обновить Gogs 0.9.99.0903 до Gitea 1.1.0?

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

Я думаю, вы могли бы перейти с Gogs 0.9.99.0903 на Gitea 1.1.0.

@tboerger как насчет того, чтобы сделать что-то подобное? https://blog.codeship.com/using-docker-build-debian-packages/

@lunny Я предполагаю , что @jhasse означает обновление на apt-get upgrade

Простое обновление apt-get не сработает, так как у нас будет другое имя пакета. Но я думаю, что сработает apt-get remove gogs && apt-get install gitea :)

Затем им нужно скопировать app.ini Gogs в Gitea.

Затем им нужно скопировать app.ini Gogs в Gitea.

Однако они должны сделать это до apt-get install gitea , иначе служба уже была бы запущена.

@jhasse IIRC Правила упаковки Debian запрещают автоматическое включение служб при установке :wink:

Вы можете настроить это: http://askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

И я думаю, что по умолчанию в Ubuntu они автоматически включаются. По крайней мере, когда я устанавливал Gogs на Ubuntu 14.04, мне не нужно было делать это вручную.

Это правда, что packager.io выполняет перенос бинарных файлов, но это необходимо для gogs/gitea. Необходимо настроить несколько переменных среды и т. д. Я обнаружил, что CentOS 6 gogs RPM очень прост в установке и настройке.
Какое бы упаковочное решение вы ни выбрали для gitea, убедитесь, что его легко установить, настроить и обновить.

Многие пакеты полагаются на переменные окружения, но по-прежнему нет необходимости оборачивать двоичный файл. А простота установки и настройки всегда в центре внимания пакета или нет?

Так что на самом деле у меня есть gitea, упакованный в .deb . Я не разрешаю ничего на моем сервере, что не упаковано должным образом. На данный момент это немного лоскутная работа (отчасти из-за этого # 480).

Что касается пути обновления... Пакеты .deb позволяют объявлять некоторые файлы как файлы конфигурации, которые менеджер пакетов будет:

• Сохранить после удаления пакета до тех пор, пока пользователь явно не "очистит" пакет
• Проверьте наличие изменений перед перезаписью с помощью обновления. Он спросит пользователя, что делать, если конфигурация изменилась.

Это позволяет .deb включать файл app.ini по умолчанию, содержащий набор значений по умолчанию, которые отличаются от основных значений по умолчанию gitea (например, пути к файлам, упомянутые в #480).

Существует также механизм устаревания других пакетов (таких как gogs), но он может быть менее полезным, если gogs был установлен без .deb

Для всех, кто заинтересован в том, чтобы покопаться в моем коде конфигурации, он находится здесь: https://github.com/couling/gitea/tree/dpkg-config/scripts/dpkg .

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

@jhasse IIRC Правила упаковки Debian запрещают автоматическое включение служб при установке 😉

Это интересно. Каждый серверный пакет (включая такие вещи, как apache2) запускал службу при установке.

@couling , не могли бы вы отправить PR?

@tboerger какое-нибудь обновление?

С моей стороны обновлений пока нет. ИМХО, нам нужно запускать разные контейнеры докеров, чтобы убедиться, что они правильно соответствуют целевой ОС (ссылаясь на проблему с glibc). Кроме того, рабочий процесс докера исключает 32-битные системы и другие архитектуры, поскольку мы пока не можем поддерживать это с нашей цепочкой сборки.

Итак, давайте поместим это в v1.2?

Я не уверен, что это полезно. Но у меня есть экспериментальная библиотека/инструмент Golang для создания пакетов Debian вообще без использования debian (только родной golang). У меня также были некоторые «проблемы» при создании пакетов для Debian «кросс-платформенным» способом, и я не большой поклонник dpkg builder. Посмотрите: https://github.com/xor-gate/debpkg

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

@xor-gate спасибо, посмотрю, когда вернусь к этому вопросу.

Я собирался попробовать упаковать Gitea для Debian, но вижу, что кое-кто меня опередил — см. Debian Bug 79210 .

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

Мне больше всего нужна помощь в написании описаний пакетов для всех зависимостей gitea, которые в настоящее время не упакованы в Debian. Это занимало не менее 80% моего времени, потому что мои навыки работы с Golang слабы, и многие из этих сотрудников практически не описывают то, что они делают. Я также боролся с некоторыми другими вещами, связанными со сборкой Debian.

Если вы или кто-то еще хочет 1. установить Debian 2. apt-get установить gitea, хотите помочь мне, не стесняйтесь связаться со мной по IRC! MTecknology @ Freenode/OFTC

@MTecknology Вы меня опередили - я собирался написать вам по электронной почте и посмотреть, могу ли я чем-нибудь помочь. У меня есть достаточный опыт упаковки Debian (я почетный разработчик), хотя я не занимаюсь упаковкой приложений Go, и приличный опыт разработки Go. Скоро свяжусь через IRC

@mjturner Кажется, я тебя напугал! Если вы все еще заинтересованы, я нахожусь в том месте, где это становится немного ошеломляющим, и мне действительно не помешала бы рука.
или.. кто-нибудь еще? Кто-нибудь вообще разбирается в пакетах Debian и/или Go? Ну пожалуйста?... :cry:

Привет, ребята, упаковка Debian не очень интуитивно понятна, потому что она очень и очень гибкая. Большинству людей просто нужны некоторые файлы внутри .deb и некоторые метаданные (пакеты, версия, описание). Я думаю, что самый быстрый способ — использовать некоторые инструменты внешнего интерфейса для создания простого пакета Debian. Например, https://github.com/laher/goxc или https://github.com/jordansisssel/fpm.

Ребята из Syncthing (проект golang) используют FPM для сборки пакета debian в своем скрипте build.go :
https://github.com/syncthing/syncthing/blob/2579e8f7152c3205691f3798a81d43c1af4e8af6/build.go#L531 -L539

Некоторые люди уже вложили некоторые усилия в систему сборки Debian Make, чтобы иметь dh-make-golang (помощник debian make для golang), см . https://github.com/Debian/dh-make-golang.

Чтобы упаковать Debian, нужно немного любви, но это стоит затраченных усилий.

@MTecknology Извинения! Я определенно не испугался, я просто был настолько завален кучей других вещей, что у меня не было возможности еще раз взглянуть на Гитею с момента нашего последнего контакта несколько недель назад :(

Мое время все еще довольно ограничено на данный момент, но я все еще очень заинтересован в том, чтобы принять участие.

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

Оказывается, мне нужны дополнительные библиотеки javascript. Дальше... уууу..... :sob:

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

@mjturner , хе-хе... вы действительно разместили ссылку на то место, где я разместил ссылку на свой WIP (ошибка Debian)
--> https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress

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

На данный момент мне нужна помощь с пакетами/зависимостями javascript.

Это, среди прочего, будет отложено выпуском #1484, но выпущен Debian 9, и я планирую снова добиться некоторого прогресса в ближайшем будущем. Еще многое предстоит сделать, но когда-нибудь я закрою эту херню!

привет, кто-нибудь успешно сделал rpm в fedora/centos/rhel?

@tboerger - Мне очень нравится то, что вы и ваша команда делаете с Gitea! Чтобы решить проблемы людей с тем, что у Gitea еще нет RPM, я написал инструмент для создания Gitea RPMS для производных Red Hat 6.x и 7.x. Я уже некоторое время тестирую его локально, и я действительно близок к тому, чтобы выпустить его в ближайшие день или два.

Не уверен, ищете ли вы решение GO для создания RPMS или вам просто нужен процесс, который создает RPM. Мой инструмент (хотя он в основном написан на питоне) будет генерировать RPMS, соответствующие стандартам упаковки Redhat.

Не уверен, готовы ли вы использовать такой инструмент, но я планирую выложить свой общедоступный gitub в ближайшие день или два.

Мы всегда открыты для пиара, даже если не объединимся, это может быть полезно другим. Вы можете использовать папку contrib для хранения вашего скрипта. В целом мы стараемся придерживаться golang, но для конкретного случая мы делаем исключение, а python является распространенным инструментом.

@codylane с нетерпением жду этого! Я работал над этим, используя способ упаковки Fedora, но я едва знаю, как это сделать, и собирался быть выстрелом в темноту.

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

Я был бы рад отправить запрос на вытягивание в gitea, просто подумал, что сообщество может помочь мне убедиться, что он работает, прежде чем он попадет в ваше репо. У меня есть много интеграционных тестов вокруг RPM, но лучший способ убедиться, что он работает, — это выступить перед людьми. :)

Еще раз спасибо за создание такого замечательного инструмента с открытым исходным кодом!

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

Прохладный. Мне также нужно проверить дрон, и он был в моем списке вещей, с которыми можно поиграть.

Как и было обещано, вот автоматизированный процесс CI для сборки Gitea RPM для CentOS 6 и 7. https://github.com/codylane/gitea-rpm.

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

Вы думали об использовании Copr ?

Может кто пришлет ПР на изменение файла дрона для генерации дэба? @tboerger @bkcsoft @appleboy

@jhasse , чем мы также можем использовать открытый сервис сборки. Я не считаю, что эти инструменты являются лучшим выбором.

Я бы предпочел дрон-плагин для rpm и deb и размещать репозитории самостоятельно или на bintray/packagecloud.

@tboerger - Просто любопытно, не хотите ли вы, чтобы я попробовал дроны? Причина, по которой я спрашиваю, заключается в том, что я думал о подключении своего репозитория к TravisCI. Я полностью понимаю, если вы, ребята, предпочитаете автономную службу сборки. :)

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

В настоящее время мы используем в основном плагины, созданные участниками Drone из организации Drone-Plugins github, @thomasf начал создавать Drone-Deb для упаковки на основе Debian, и я хотел бы запустить плагин Drone-RPM в рамках Drone-Plugins org.

Вы можете увидеть наш .drone.yml в корне проекта, мы размещаем наш экземпляр дрона на сайте drone.gitea.io.

Прохладный. Как только я решу эту проблему с systemd, я посмотрю, как вы рекомендовали. Спасибо чувак!

К вашему сведению — проблема с systemd была решена, и RPM должны быть в хорошем рабочем состоянии. Еще нужно разобраться с дронами.

Просто добавлю еще одну идею, чтобы предоставить простые средства установки через «пакет» под Linux: http://linuxbrew.sh.

Привет, есть новости о пакетах deb? Мне бы очень хотелось иметь пакет gitea deb;)
На самом деле они мне понадобятся для Ubuntu 16.04 и Ubuntu 18.04, если быть точнее...

Я также готов сделать пакет Debian и сделать его доступным, если этот шаг не был сделан раньше, просто дайте мне знать ;)

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время в ней не было активности. Он будет закрыт, если в течение следующих 2 недель не будет никакой активности. Спасибо за ваш вклад.

Спасибо stalebot за ваш вклад.

Я все еще продвигаю свой пакет github.com/xor-gate/debpkg go для упаковки Debian 🎉 .

@xor-gate, не могли бы вы отправить PR, чтобы добавить файл конфигурации для вашей библиотеки на contrib? Возможно, мы могли бы выпустить его в плагине для дронов.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время в ней не было активности. Он будет закрыт, если в течение следующих 2 недель не будет никакой активности. Спасибо за ваш вклад.

Пожалуйста, примите во внимание спрос на это...

Только несвежий из-за отсутствия решения.

Я не думаю, что у кого-то есть достаточно энергии, чтобы упаковать gitea для
Debian main, слишком много зависимостей с типичным golang
экосистемные проблемы [1]. Я потратил более года на > 30 часов в неделю, пытаясь это сделать
случаться; когда я сдался, потребовалось менее трех месяцев для библиотеки, которую я
помещен в Debian для извлечения из архива из-за критических изменений в
зависимости.

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

[1]

• Некоторые библиотеки мертвы, и в них обнаружены ошибки безопасности.
• Многие библиотеки были разветвлены с разным уровнем обслуживания (в основном
  почини и забудь)
• Новые библиотеки добавляются произвольно, часто практически без проверки.
• 'иди поставщик' (curl | sudo -)
• Более 200 разработчиков golang редко выпускают релизы (ожидая, что приложения всегда
  вытащить последнюю версию git, включая любые дополнительные добавленные библиотеки deps)

Кроме того-

• Кажется, не существует метода координации обновлений безопасности (с
  мышление, что обновление обеспечивает вашу безопасность... оно делает противоположное)
• >200 библиотек golang бледнеют по сравнению с >2000 js-библиотек.
• Существует ужасное отсутствие заботы о том, что может быть включено в
  программное обеспечение с открытым исходным кодом
• Попытки исправить эти проблемы встретили значительное сопротивление.

Хотя можно упаковать gitea для дистрибутивов, которые не возражают
эти проблемы с лицензированием и совместимостью, я сдался, когда понял это
никогда не сможет выжить в Debian main без команды мазохистов с целой
много времени доступно не только для первоначального выпуска.

Опять же, я рад помочь всем заинтересованным, но я лично перешел к
создание более минималистического «клона», который устраняет эти проблемы. (Медленный
поеду из-за мало времени)
... Если кому-то интересен мой проект или работа над gitea для
Debian, обратитесь к MTecknology на Freenode.

>

@MTecknology есть PR для решения этой проблемы. см. https://github.com/go-gitea/gitea/pull/6671 .

Он не решает ни одной из упомянутых мною проблем, он просто представляет их все в удобном пакете, который по-прежнему не подходит для архива Debian.

А как насчет предоставления ppa (который мы бы разместили) для предоставления автоматически собираемых пакетов Debian?

Можно было бы подумать, что библиотеки JS будут в комплекте с самой gitea - я всегда избегал версий так называемых библиотек javascript, доступных через apt, потому что вы не можете гарантировать, какая это версия.

Что касается библиотек go, я думал, что Gitea выпустила только один двоичный файл? Это то, что я использовал, по крайней мере. Нельзя ли создать простой репозиторий apt с пакетом, содержащим этот единственный двоичный файл?

Отказ от ответственности: я _не_ сопровождаю Debian, и у меня довольно ограниченный опыт упаковки вещей в файлы .deb. Мой опыт доходит до fpm

@MTecknology Вы проделали огромный объем работы, но, к сожалению, я чувствую, что пакет gitea для Debian не обязательно имеет смысл. В проекте нет цели поддерживать старые версии с помощью исправлений безопасности или ошибок, которые соответствовали бы циклам выпуска Debian. И, как вы упомянули, количество зависимостей неуправляемо. Пословица «Немного копирования лучше, чем небольшая зависимость». был проигнорирован. Но это также вполне понятно, так как это добровольная работа с небольшими ресурсами для таких вещей, как поддержание зависимостей в актуальном состоянии или рефакторинг скопированного кода, чтобы включать только необходимые вещи, а затем портировать исправления. А мир зависимостей JS/NPM еще хуже. Я считаю, что программное обеспечение, такое как gitea, лучше предлагать в виде образов докеров, которые работают с несколькими дистрибутивами Linux. Надеемся, что образы докеров заблокированы, поскольку в коде все еще есть проблемы с зависимостями и исправлениями безопасности, о которых вы упомянули.

Предоставьте репозиторий yum, и источник apt будет другим, а сценарий оболочки установки будет другим выбором.

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

Чтобы избежать такого кошмара с пакетами, мы могли бы просто собрать пакеты deb и rpm, которые предоставляются через bintray или даже через какую-то папку на зеркале загрузки, которая поддерживается cdn cloudflare.

Сами пакеты могут быть созданы с помощью fpm, или кто-то внесет плагин для дронов, который может даже попасть в организацию Drone-Plugins, если он написан на Go и соответствует некоторым стандартам. Существует даже библиотека go, в которой реализовано множество функций fpm.

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

Меня также беспокоит количество внешних зависимостей, которые у нас есть — нам определенно следует подумать о том, нужны ли они нам как жесткие зависимости (например, великолепный, Boltdb) и могут ли некоторые из наших меньших зависимостей выиграть от разветвления или перезаписи. (Сессия Macaron и go-ini проблематичны, имхо.)

Нам также необходимо реорганизовать нашу внутреннюю структуру, чтобы сделать плагины Go реальностью. Я думаю, это позволило бы нам сделать более компактный core-gitea, который можно было бы упаковать без добавления всех других зависимостей.

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

Говоря как сопровождающий Debian, было бы очень здорово иметь gitea в Debian как сам пакет. Но есть технические (и, возможно, лицензионные) проблемы с ним, так что это выходит за рамки этого вопроса.

Говоря как пользователь Debian, было бы здорово отправить gitea через пакет deb. Поскольку у нас уже есть статический бинарный файл go, его можно отправить в нем. Преимущество этого заключается в том, что мы также можем включить соответствующую инфраструктуру, такую ​​​​как юнит-файлы, для ее запуска при запуске системы и, возможно, нормальную конфигурацию по умолчанию, если это необходимо.
Для большинства пользователей это означает добавление источника пакета, добавление ключа подписи и просто установка пакета. Обновления развертываются способом, с которым пользователи уже знакомы.

Обороты CentOS: https://cbs.centos.org/koji/buildinfo?buildID=25894

Было бы здорово добавить rpm в часто обновляемый репозиторий dnf/yum, чтобы пользователи дистрибутива rpm могли легко получать последние обновления безопасности и т. д. для gitea.

@waja Какие-либо изменения в вашем пакете CentOS обновляются для Fedora и, возможно, добавляются в EPEL, если он протестирован и стабилен?

Есть новости по этому поводу? Месяц назад @techknowlogick в #6671 сказал, что Drone можно использовать для автоматизированной сборки rpm и deb. Кому-то удалось найти момент, чтобы включить его? Если да, не могли бы вы обновить документацию?

@Janhouse Я пытался упаковать это для Fedora, но правильно упаковать Go очень сложно. Версия CentOS, указанная выше, на самом деле не собиралась должным образом для меня, и я заметил некоторые изменения, которые должны были произойти с ней.

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

@waja ничего не знает о размещении проекта в официальном репозитории debain, но у alpine-linux уже есть рабочий пакет: источник

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

Насколько сложно поддерживать ppa?

Не особенно сложно, @ 6543. На самом деле у меня есть собственный репозиторий apt здесь: https://apt.starbeamrainbowlabs.com/

Код, который я использую для управления, можно найти здесь: https://git.starbeamrainbowlabs.com/sbrl/aptosaurus .

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

Сборка пакета должна выполняться дроном, а затем он должен быть просто загружен в бинтрей ;)

@tboerger Попробую сделать набросок PR со скриптом сборки deb...
и у нас есть dl.gitea.io стоит ли заливать туда деб (и возможно как аттач при релизе)

Я лично не хотел бы самостоятельно управлять репозиториями deb и rpm, поэтому Bintray отлично подходит для этого. Просто загружать файл deb или rpm без какого-либо репозитория, ИМХО, довольно бесполезно.

Просто загружать файл deb или rpm без какого-либо репозитория, ИМХО, довольно бесполезно.

это вообще нонсенс!

Мы также можем использовать nfpm для сборки файлов deb и rpm.

Некоторое время назад кто-то уже начал создавать плагин для дрона fpm... Я все еще хочу создать его в рамках организации плагинов на основе форка go fpm.

Вот плагин дрона, который я сделал для nfpm: https://github.com/techknowlogick/drone-nfpm .

Если вы делаете пакеты для систем FHS, не забудьте либо использовать сценарий теневого копирования в contrib, либо собрать с правильно установленным LDFLAGS.

Привет всем, у меня есть собственный репозиторий пакетов APT, я могу добавить в него gitea.
Смотрите уже включенный проект: https://packages.azlux.fr/
Теперь он работает, легко добавить любой .deb, который вы хотите (я даже могу его создать)

Азлюкс

@azlux все сводится к доверию. Вы, вероятно, классный парень, но я бы предпочел установить его из какой-нибудь известной службы автоматизации, где скрипты сборки поддерживаются командой разработчиков gitea, чем получить его из какого-то частного репозитория. У меня также есть свои собственные пакеты, но в идеале ими будет управлять команда gitea.

Крюк
Спасибо за информацию @Janhouse
Я настроил свое репо с помощью reprepro, я могу помочь, если вам нужно.

Аз

@Janhouse После более глубокого размышления репозиторий apt позволяет нам убедиться, что источники за это время не были изменены. В идеале лучше, чтобы gitea поддерживала собственное репо, но они также могут поместить другое репо в качестве «неофициального репозитория».
У многих проектов нет проблем с этим. Вот так, Люди предупредили.

Я знаю, что говорил это раньше, но...

Если вы предоставляете пакеты Deb, вам, вероятно, следует собрать Gitea так, чтобы он подчинялся FHS, установив LDFLAGS, как описано здесь:

https://docs.gitea.io/en-us/install-from-source/#change-the-default-custompath-customconf-and-appworkpath

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

Я также хотел бы, чтобы gitea следовала за FHS @zeripath , это глупо, им тоже нужен сценарий оболочки-оболочки.

Есть какие-нибудь новости о RPM? Я вижу много дискуссий о DEB, но многие предприятия будут использовать CentOS, который не использует пакеты DEB. Кажется, что BSD имеют свои собственные пакеты (с исправлениями), но их процессы немного отличаются.

@evitalis вам не нужен скрипт, если вы создадите его с соответствующими LDFLAGS.

Я знаю, я имел в виду их потребность даже в этом .

Просто думаю об этом. Путь FHS должен быть по умолчанию для версии 2, так как это было бы необходимым критическим изменением.

Я думаю, нам нужно немного сломать это. В настоящее время существует четыре вида сборки:

• сборки для разработки - вы загружаете исходный код и строите с помощью make
• личные сборки - вы загружаете исходный код и строите с помощью make, но хотите, чтобы это был работающий сервер
• релизные сборки — собираем с помощью make release и втыкаем на gitea.io и GH
• докер строит

FHS по умолчанию имеет смысл для двух из них: выпуск и, возможно, личная, но в настоящее время вы не можете сказать, является ли личная сборка сборкой для разработки или наоборот. Ломать сборки разработки было бы очень плохой идеей.

Докер также должен иметь встроенные значения по умолчанию — бессмысленно требовать «-c» по умолчанию для сборки докера, которую мы создаем сами.

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

Когда я впервые запустил опцию LDFLAGS, я предложил:

• Сделайте отдельный релиз со встроенными путями FHS
• Сделайте так, чтобы в докере были встроены пути по умолчанию для докера, что решает несколько других странных проблем с запуском gitea в командной строке докера.
• Добавить/открыть конечную точку make для сборок FHS, которая правильно устанавливает флаги <- сборщики пакетов должны использовать это...

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

Альтернативой является добавление скрипта configure и создание конечных точек установки, так как тогда это будет выглядеть «нормально» для людей, привыкших к:

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

Абсолютно нормально искать конфигурации по предопределенным путям, если вы не указали флаг для пользовательского пути. Это, например, уже часть https://github.com/spf13/viper для определения нескольких стандартных путей. Нынешнее испорченное поведение Gitea совершенно необычно.

Возможно, стоило бы сначала поместить сборки релизов в репозитории, это было бы хорошим первым шагом?

@sbrl уже сделано в моем репо , скрипт сборки хранится здесь: https://github.com/azlux/dpkg-deb
Как вы сказали, он использует непосредственно сборку релиза.

@zeripath Я думаю, что вы делаете это более сложным, чем нужно, основываясь на вашем ответе, но я могу неправильно его истолковать. Если люди используют git clone и создают что-то сами, они должны знать, что могут возникнуть проблемы. Для многих проектов выполнение указанной сборки из ветки master или использование релиза считается стабильным, все остальное — нет и может сломаться в любой момент.

Даже в Docker нет причин не следовать FHS, так что этот случай тоже исчезнет. В остальном, как отмечает @tboerger , проверка стандартного набора путей для конфига считается нормальной. Использование только $PWD или случайных флагов компиляции, которые большинство пользователей никогда не увидят, вызывает больше проблем, в том числе с упаковкой ОС. Как человек, который упаковал больше, чем несколько вещей, чем менее стандартное приложение, тем больше работы для меня и тем больше исправлений мне, возможно, придется ввести.

Учитывая все вышесказанное, я все еще заинтересован в том, чтобы хотя бы увидеть официальные RPM. Я не использую Debian или Ubuntu, но я уверен, что официальный DEB также приветствуется. Спасибо всем в этой теме, которые тем временем делают все возможное для упаковки.