Состоялся (https://blog.gitea.io/2016/12/release-of-1.0.0/) первый релиз проекта Gitea (https://gitea.io/), в рамках которого развивается легковесная система для организации совместной работы с репозиториями Git, позволяющая на собственном оборудовании или в облачных окружениях развернуть сервис, напоминающий GitHub, Bitbucket и Gitlab. Код проекта написан на языке Go и поставляется (https://github.com/go-gitea/gitea) под лицензией MIT. Система имеет достаточно низкие требования к ресурсам и может быть развёрнута на плате Raspberry Pi.
Одной из целей проекта является максимальное упрощение процесса развёртывания платформы для совместной разработки, благодаря использованию языка Go этого удалось добиться сформировав готовые бинарные сборки, подготовленные для различных ОС и архитектур, включая Linux (x86, ARM, PowerPC), macOS и Windows. Для систем виртуализации, Docker и облачных платформ сформированы образы преднастроенных окружений.
Проект Gitea был основан (https://blog.gitea.io/2016/12/welcome-to-gitea/) в декабре 2016 года как форк проекта Gogs (https://gogs.io/), созданный группой энтузиастов, недовольных организацией управления в проекте. Главными мотивами создания форка было желание передать управление в руки сообщества и упростить участие в разработке независимых разработчиков. Вместо применяемой в Gogs модели, основанной на добавление кода только через одного главного мэйнтенера, который единолично принимает решения, в Gitea применена модель разделения полномочий с предоставлением права добавления кода в репозиторий нескольким активным разработчикам.Мэйнтейнером сможет стать каждый, от кого принято более трёх коммитов, если кандидатура будет одобрена в ходе голосования разработчиков. Кроме того, ежегодно будут выбираться три участника, которые будут коллективно принимать связанные с проектом решения. По мнению создателей Gitea подобный подход поможет избавиться от лишней бюрократии, существенно ускорит разработку и сделает проект более привлекательным для новых участников.
Основные возможности (https://docs.gitea.io/en-us/) Gitea и Gogs:- Отображение активности по шкале времени;
- Доступ к репозиторию по протоколам SSH и HTTP/HTTPS;
- Аутентификация через SMTP, LDAP и Reverse proxy;
- Встроенные средства управления учётными записями, репозиториями и организациями/командами;
- Интерфейс для добавления и удаления разработчиков, имеющих доступ к добавлению данных в репозиторий;
- Систем web-хуков для интеграции обработчиков от сторонних сервисов, таких как Slack;
- Наличие интерфейсов для приёма сообщений об ошибках (issues), обработки pull-запросов и Wiki для подготовки документации;
- Средства для миграции и зеркалирования репозиториев и wiki из других систем;
- Web-интерфейс для редактирования кода и wiki;
- Загрузка аватаров через Gravatar и сторонние сервисы;
- Сервис отправки уведомлений по электронной почте;
- Панель администратора;
- Многоязычный интерфейс;
- Поддержка хранения параметров в MySQL, PostgreSQL, SQLite3, MSSQL и TiDB.
После ответвления в Gitea 1.0.0 принято 238 (https://github.com/go-gitea/gitea/pulls?utf8=%E2%9...) pull-запросов и исправлено 44 (https://github.com/go-gitea/gitea/issues?q=is%3Aissue+i...) проблемы. Проведена ревизия и переработка API. В интерфейсе обеспечен показ последнего входа для администраторов. Интегрирована поддержка тестового набора DroneCI и менеджера зависимостей. Добавлена возможность встраивания бинарных данных. Переработана структура контейнера для Docker. Реализована поддержка загрузки по коротким ссылкам. Добавлена поддержка настраиваемых SSH-биндингов.URL: https://news.ycombinator.com/item?id=13296717
Новость: https://www.opennet.ru/opennews/art.shtml?num=45802
Из gogs они продолжают мержить изменения?
Ага, прилетает pull request в gogs тут же набегают тролли из gitea и орут, что вы теперь должны слать свои патчи в gitea. Прилетает issue с брешью в безопасности, прибегают тролли из gitea и орут вы теперь должны нам слать на мыло. Авторы им отвечают вам никто ничего не должен, берите и сами переносите. Я собственно не против форка и скорость разработки там действительно выше. Но такие разработчики gitea несколько портят имидж.
> орут
> орутУ тебя гиперакузия?
> Авторы им отвечают вам никто ничего не должен, берите и сами переносите.Ну так у них тоже опенсорсный продукт, и они тоже никому ничего не должны. Такие уж времена пошли -- безответственные.
подождём несколько месяцев и поставим. главное, не забывайте новости об этой штуке писать :)
+1
Gogs отличный инструмент, но если в Gitea сделают его лучше то я буду совсем не против и с радостью на него перейду.
Главное, чтобы решили привести wiki в идеальное состояние, в то сейчас там ну очень обрубок длоя helloworldов
Так и не понял, чем оно лучше GitLab?
Оно несравнимо легче.
Спасибо, тогда пощупаю его на малине:)
Для тех, у кого аллергия на руби..
gitlab поставить и инфраструктуру сделать - проще в космос слетатьа gogs легко ставится хоть на arm с любым linux, у которого есть go, хоть на OpenBSD (единственный косяк - если в системе не установлен bash, то работать не будет - выяснено эмпирическим путём)
а зачем ты удаляешь bash в Линуксе ?)
> хоть на OpenBSD (единственный косяк - если в системе не установлен bash, то работать не будет - выяснено эмпирическим путём)какие буквы непонятны?
точно, чего-то про linux подумал
кстати, в конфиге можно указывать оболочку под которой должен работать gogs, по дефолту там bash стоит. У меня тоже по началу не запускалось так как использовалась оболочка zsh, после правки конфига всё отлично заводится.
Не нужен там го, компилируешь, если так надо из сорцов, бинарь и кидаешь на свою железку, всё.
> Не нужен там го, компилируешь, если так надо из сорцов, бинарь и
> кидаешь на свою железку, всё.ээээ, там как бы архитектуры разные
Про переменную GOARCH почитай.
> Про переменную GOARCH почитай.из OpenBSD amd64 можно собрать для Linux armhf?
Да. Полно блогпостов с инструкциями https://www.alexruf.net/2016/01/16/cross-compile-with-go-1-5...
есть такая штука как кросс-компиляция
Бздунам это не понять.
> gitlab поставить и инфраструктуру сделать - проще в космос слетатьСтранно слышать это от BSDшника. Ставится из портов и работает. Никакого космоса.
я не знаю, кто такие БСД-шники, но у меня в OpenBSD его в портах нет. В Debian Stable тоже нет. Есть в Debian Testing, но я ещё не пробовал из пакетов ставить - gogs гораздо проще и быстрее.
>> я не знаю, кто такие БСД-шники...И с этим не поспоришь.
yum install gitlab-ce
пора кодить в телефоне)
> Вместо применяемой в Gogs модели, основанной на добавлении кода только через одного главного мэйнтенера, который единолично принимает решения, в Gitea применена модель разделения полномочий с предоставлением права добавления кода в репозиторий нескольким активным разработчикам.Авторитаризм vs демократия? Делаем ставки, господа.
неа, хозяева vs пользователии тут всё очень сильно зависит от того, кто хозяева и кто пользователи.
в данном конкретном случае:
про хозяев не скажу (какая у них бизнес-модель и чего хотят достичь - я не знаю), но пользователи gogs практически поголовно программисты, поэтому писать нужные патчи смогут многие. поэтому тут такая народная модель коммитов - в самый раз (в разумных пределах, конечно - но, в принципе, все репозиторники на одно лицо, особо не пофантазируешь).
> поэтому писать нужные патчи смогут многие. поэтому тут такая народная модель коммитов - в самый разhttps://github.com/gogits/gogs/pulls?q=is%3Apr+is%...
Pull requests: 33 open, 1040 closed
Из них 716 merged
gogs, разрабатывающийся на гитхабе - это круто. они как бы говорят всем нам *нуууу... вы понимаете? используйте github*kallithea разрабатывается в kallithea: https://kallithea-scm.org/repos/
fossil разрабатывается в fossil: http://fossil-scm.org
> kallithea разрабатывается в kallithea: https://kallithea-scm.org/repos/Ну почти: For now, we use Bitbucket for pull requests and issue tracking.
Так что оно лишь хостится на себе, а разработка идет в bitbucketЕсли глянуть другие альтернативы github, то можно заметить, что использование github для их разработки это обычная практика. Что конечно печально.
> fossil разрабатывается в fossil: http://fossil-scm.org
Ну да, у этих ребят есть яйца.
В момент начала проекта он был сырым и глючным. Сейчас дела обстоят лучшее, но ошибки встречаются. Большая часть функционала, не связанная с управление репортерами и репозитариями просто использует другие готовые проекты, что приводит к казусам: вы не можете использовать картинки из репов wiki, зато не приходится искать ошибки в других проектах
Уже спрашивал, но повторюсь: Хоть кто-то реализовал межсерверные мерж-реквесты?
man git-am
man git-applyиди учи матчасть
Вот бы так и с OpenOCD (http://openocd.zylin.com/). Патчей немерено лежит, а мержить не хотят. Лишь бы релиз следующий выпустить с горсткой самых-самых надёжный исправлений. А то, что писал не самый главный мэйнтейнер, нельзя считать самым-самым надёжным, а значит, пусть лежит в сторонке.
Зачем на Go? У них там что, так много мультипоточного программирования с обменом мессагами? Это же просто request-response логика.
Потому что шустрее получается и менее затратно по потребляемым ресурсам по сравнению с решениями на руби и ему подобными...
Не ну я же не говорил "Руби". Он вообще для серьёзных проектов вообще не подходит, проверено практикой (я работал вместе в одной компании с большой командой рубистов на большом проекте).Для более-менее серьёзных веб-сервисов сейчас дефолт -- Java, и JVM-образные языки. На Python тоже можно что-то до среднего размера написать. Тут же основное дело в библиотеках.
> Не ну я же не говорил "Руби". Он вообще для серьёзных проектов вообще не подходит, проверено практикой (я работал вместе в одной компании с большой командой рубистов на большом проекте).Эксперт в треде, все в компилятор! Расскажи это Shopify, а то они там как раз серьёзный проект, большой очень и именно на Ruby пишут. Работал он, ты ж понимаешь.
Писать просто потому что. И особенно деплоить. А на чём ещё?
Наркоманы наверное про свой кристальный руби
https://crystal-lang.org/
> Наркоманы наверное про свой кристальный руби
> https://crystal-lang.org/Не, я имел ввиду Java (и JVM-ные языки) или C# (см ниже я объяснил почему). Уж лучше Go, чем Руби.
На с++, ну или хотя бы на rust.
> Писать просто потому что. И особенно деплоить. А на чём ещё?Писать, а особенно деплоить, проще на той же Java или C# (или языках на их основе).
Проблемы возникают только у тех, кто не хочет учить нормальные IDE и продолжает писать в Vim-ах и прочих Блокнотах.
Уже сейчас ReactiveX гораздо мощнее gorotines + channels в Go, и общий для всех языков, так что вместе с стрелочными функциями в Java 8 вообще не вижу зачем в веб-серверах может понадобится Go. Для роботов -- пожалуйста.
> Зачем на Go? У них там что, так много мультипоточного программирования с
> обменом мессагами? Это же просто request-response логика.Модно - молодежно.
>> Зачем на Go? У них там что, так много мультипоточного программирования с
>> обменом мессагами? Это же просто request-response логика.
> Модно - молодежно.Это точно, слишком много hype вокруг Go. Они недавно заявили что сделают лучший в мире garbage collector. Хотя по факту замолчали все недостатки, да и ничего нового они в сфере GC вряд ли придумают, там учёные уже 50 лет работают. Тут подробнее: https://medium.com/@octskyward/modern-garbage-collectio...
> Зачем на Go?Ну очевидно же: чтобы позлить тебя персонально и других я-знаю-как-лучше-мам-ну-скажи-им с Опеннета.
Ну во-первых Go это не только горутины. Во-вторых дистрибьютить намного легче и безгеморно, не то что ваша Java (нужно будет заворачивать JVM в архив с программой) или Python ( py2exe ??? ). Это же продукт который можно поставить на локалхолст, а не сервис. На какую-нибудь малинку например или прочие одноплатники. Тащить туда жабу, ну его нафиг.
А правами на ветки репов назначать пользакам можно на Gogs?