Я не слышал про такое в планах, но возможность добавлять SSH-ключи для групп звучит интересно.
Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?
Можно прописать чтобы в staging деплоились все ветки кроме master. А в production — только master. Это делается с помощью опций only и except. Кусок конфига:
В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:
Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.
Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:
new — тикет создан, но ни на кого не навешан
research — тикет на кого то навешан, но не создан MR
development — создан MR с пометкой [WIP]
testing — MR перевешан на тестировщика, из названия MR убран [WIP]
По (1) — маловато информации для создания issue имхо. Вот бы чуть побольше деталей: какие команды выполнялись, может пример лога, или ссылка, если проект публичный.
Да, обычно в описании просто создается список задач: https://gitlab.com/gitlab-org/gitlab-ce/issues/14838
Мне нравится идея для задач, где в описании есть такие списки, показывать процент выполненного на основе проставленных галочек. Запилю feature request, если этого еще нет в планах.
А какие у вас статусы у задач и для чего вы их используете? Интересно какой у вас процесс разработки.
Спасибо за ваше мнение. Я думаю что продукты нужны всякие.
И видимо ГитЛаб просто не подходит для ваших нужд и вашего процесса разработки.
C Jira трекер ГитЛаба сравнивать не надо. Это очевидно продукты в совершенно разной весовой категории. Если уж сравнивать, то с ГитХабом.
P.S. я надеюсь что ГитЛабовский трекер никогда не превратится в Jira. Это было бы печально.
ГитЛаб — сравнительно молодой продукт, и было бы странно расчитывать на такую же его поддержку как и ГитХаба. Но это плавно меняется, кстати говоря. Ваш пример — тому подтверждение. +Картинка с google trends:
Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.
1) Привет. А расскажи, чего по твоему не хватает в GitLab CI? Я сейчас как раз работаю над статьей про него.
2) Что не так с "merge when builds"? Я правильно понял что вы не пользуетесь CI, и эта фича как-то мешала вам?
3) Я думаю что "никто" — это все таки преувеличение. Понятно что если у вас уже есть issue трэкер, которым вы пользуетесь годами, переезжать на новый — трудозатратная процедура. Насколько я знаю, интеграция с Jira есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?
1) Могу пояснить за комбайн :)
Я поначалу как пришел в ГитЛаб, тоже недоумевал, почему в 2016 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:
В чате обсудили фичу
Из этого же на лету создали issue
Поставили в план в issue board
Прямо в браузере закодили чего-нибудь с помощью встроенной IDE, если не охота чекаутить на локальную машину
Тесты прогнались в CI
Провели Code review в Merge Request-e
Задеплоили из того же CI
Задокументировали чего надо в Wiki
Это то направление, куда движется продукт. Подробнее здесь. Надеюсь теперь этот комбайн начал обретать некоторый смысл для вас
2) За счет того что CI встроен в ГитЛаб, не нужно бегать между двумя сервисами, все в одном интерфейсе, и стало возможным запилить фичу "Merge when build succeed" — т.е. не нужно бегать и проверять а прошел ли билд, чтобы смержить его руками. Поставил галку — и иди занимайся следующей фичей.
3) Насчет CI и yml-файлов. А по-другому — это как? Я просто сам рубист, и у нас так все жизнь везде было, и это кажется очень естественным способом конфигурить. Опять же, version control для самого конфига — это же добро, не так ли?
Мне вчера попалась презентация про GitLab CI (ее автор никак не связан с ГитЛабом) — и там в общем прямо противоположное мнение. Посмотрите.
4) Расскажите пожалуйста, чего не хватает в трекере, и в чем корявости? По-моему за последние несколько релизов его не слабо так прокачали: Due date, веса для меток, возможность создавать скрытые iussues.
5) Интеграция со сторонними компонентами не сопоставима, конечно, с тем же ГитХабом. Но и компания сама пока поменьше. Плюс, если можно встроить что-то в сам продукт, то приоритет будет отдаваться этому, нежели чем созданию интерфейсов для интеграции. Это как раз следствие философии компании.
6)
В общем, на мой взгляд, разве что для мелких красноглазых команд, которые хотят всё в одном месте чисто от лени.
Ммм, так, да не так. Большинство денег компании приносят большие компании. Для них возможность одним инструментом закрыть кучу проблема — большое благо.
Плюс им гораздо проще платить за одну тулзу, чем разбираться с ценовой политикой и политикой лицензирования десятка продуктов. Плюс потом их все еще отдельно устанавливать и интегрировать между собой.
ГитЛаб же ставится тупо с помощью apt-get install, или что там у вас в вашей операционке ;)
В переводе пропустили пример про Game assets, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.
Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:
Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.
Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.
Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.
Спам — это проблема. Но пока возможность пожаловаться на юзера решает проблему — спам аккаунты закрываются в течение дня-двух. Альтернатива — считать всех пользователей по умолчанию спамерами, и просить вводить капчу. Надеюсь до этого не дойдет. А спамеры как-то прямо вас тревожили на GitLab.com?
А, понял. Ну круто, Но у odrive принципиально другой подход, который позволяет локально держать всю структуру папок и выборочно любые файлы/папки. Такого я еще нигде не встречал.
Я не слышал про такое в планах, но возможность добавлять SSH-ключи для групп звучит интересно.
Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?
Да, это вполне вероятный сценарий, было бы круто уметь такое предотвращать. Создал тикет: https://gitlab.com/gitlab-org/gitlab-ce/issues/20481
Можно прописать чтобы в staging деплоились все ветки кроме master. А в production — только master. Это делается с помощью опций
onlyиexcept. Кусок конфига:Полный пример
Плюс в последнем релизе появилась возможность в конфиге можно указать
when: manualи руками запускать деплой, когда надо:В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:
Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.
Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:
Насчет прогресса — понял, что это уже реализовано:
Сам тикет здесь
Спасибо за репорт, я создал: https://gitlab.com/gitlab-org/gitlab-ce/issues/20479
Создал issue на (2):https://gitlab.com/gitlab-org/gitlab-ce/issues/20477
Мне кажется я тоже подобное замечал. Спрошу у ребят из команды CI сегодня про это.
По (1) — маловато информации для создания issue имхо. Вот бы чуть побольше деталей: какие команды выполнялись, может пример лога, или ссылка, если проект публичный.
Да, обычно в описании просто создается список задач: https://gitlab.com/gitlab-org/gitlab-ce/issues/14838
Мне нравится идея для задач, где в описании есть такие списки, показывать процент выполненного на основе проставленных галочек. Запилю feature request, если этого еще нет в планах.
А какие у вас статусы у задач и для чего вы их используете? Интересно какой у вас процесс разработки.
Спасибо за ваше мнение. Я думаю что продукты нужны всякие.
И видимо ГитЛаб просто не подходит для ваших нужд и вашего процесса разработки.
C Jira трекер ГитЛаба сравнивать не надо. Это очевидно продукты в совершенно разной весовой категории. Если уж сравнивать, то с ГитХабом.
P.S. я надеюсь что ГитЛабовский трекер никогда не превратится в Jira. Это было бы печально.
Вы кстати какую версию интегрировали с Jira? В Community edition полная поддержка Jira появилась только в 8.3: http://docs.gitlab.com/ce/project_services/jira.html
ГитЛаб — сравнительно молодой продукт, и было бы странно расчитывать на такую же его поддержку как и ГитХаба. Но это плавно меняется, кстати говоря. Ваш пример — тому подтверждение. +Картинка с google trends:
Упс, вот правильный линк: https://gitlab.com/gitlab-org/gitlab-ce/issues/19727
Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.
Вот пост автора ГитЛаба про редизайн: https://about.gitlab.com/2016/06/06/navigation-redesign/
1) Привет. А расскажи, чего по твоему не хватает в GitLab CI? Я сейчас как раз работаю над статьей про него.
2) Что не так с "merge when builds"? Я правильно понял что вы не пользуетесь CI, и эта фича как-то мешала вам?
3) Я думаю что "никто" — это все таки преувеличение. Понятно что если у вас уже есть issue трэкер, которым вы пользуетесь годами, переезжать на новый — трудозатратная процедура. Насколько я знаю, интеграция с Jira есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?
Чата встроенного нет, не переживайте :) Блокировка — это вообще отдельная опция для EE.
СI и issue tracker можно отключить в настройках проекта:
Спасибо за фидбэк! С 5 версии — это круто!
Создал issue про сабмодули: https://gitlab.com/gitlab-org/gitlab-ce/issues/19721
Если я что-то упустил, допишите там в комментариях плз.
1) Могу пояснить за комбайн :)
Я поначалу как пришел в ГитЛаб, тоже недоумевал, почему в 2016 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:
Это то направление, куда движется продукт. Подробнее здесь. Надеюсь теперь этот комбайн начал обретать некоторый смысл для вас
2) За счет того что CI встроен в ГитЛаб, не нужно бегать между двумя сервисами, все в одном интерфейсе, и стало возможным запилить фичу "Merge when build succeed" — т.е. не нужно бегать и проверять а прошел ли билд, чтобы смержить его руками. Поставил галку — и иди занимайся следующей фичей.
3) Насчет CI и yml-файлов. А по-другому — это как? Я просто сам рубист, и у нас так все жизнь везде было, и это кажется очень естественным способом конфигурить. Опять же, version control для самого конфига — это же добро, не так ли?
Мне вчера попалась презентация про GitLab CI (ее автор никак не связан с ГитЛабом) — и там в общем прямо противоположное мнение. Посмотрите.
4) Расскажите пожалуйста, чего не хватает в трекере, и в чем корявости? По-моему за последние несколько релизов его не слабо так прокачали: Due date, веса для меток, возможность создавать скрытые iussues.
5) Интеграция со сторонними компонентами не сопоставима, конечно, с тем же ГитХабом. Но и компания сама пока поменьше. Плюс, если можно встроить что-то в сам продукт, то приоритет будет отдаваться этому, нежели чем созданию интерфейсов для интеграции. Это как раз следствие философии компании.
6)
Ммм, так, да не так. Большинство денег компании приносят большие компании. Для них возможность одним инструментом закрыть кучу проблема — большое благо.
Плюс им гораздо проще платить за одну тулзу, чем разбираться с ценовой политикой и политикой лицензирования десятка продуктов. Плюс потом их все еще отдельно устанавливать и интегрировать между собой.
ГитЛаб же ставится тупо с помощью
apt-get install, или что там у вас в вашей операционке ;)В переводе пропустили пример про Game assets, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.
Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново
Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:
Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим
Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.
Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.
Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.