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

Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?

Да, это вполне вероятный сценарий, было бы круто уметь такое предотвращать. Создал тикет: https://gitlab.com/gitlab-org/gitlab-ce/issues/20481

Можно прописать чтобы в staging деплоились все ветки кроме master. А в production — только master. Это делается с помощью опций only и except. Кусок конфига:

`
staging:
  stage: deploy
  script:
  - deploy somehow --staging
  except:
  - master
  environment: staging

production:
  stage: deploy
  script:
  - deploy somehow --production
  only:
  - master
  environment: production
`

Полный пример

Плюс в последнем релизе появилась возможность в конфиге можно указать when: manual и руками запускать деплой, когда надо:

В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:

Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.

Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:

• new — тикет создан, но ни на кого не навешан
• research — тикет на кого то навешан, но не создан MR
• development — создан MR с пометкой [WIP]
• testing — MR перевешан на тестировщика, из названия MR убран [WIP]
• acceptance — MR перевешан на code reviewer-а
• closed — MR смержен, тикет закрыт

Насчет прогресса — понял, что это уже реализовано:

Сам тикет здесь

Спасибо за репорт, я создал: 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 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:

• В чате обсудили фичу
• Из этого же на лету создали 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, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.

Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново

Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:

1. Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим

   
   

2. Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.

   
   

3. Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.

   
   

4. Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.

   
   
5. Спам — это проблема. Но пока возможность пожаловаться на юзера решает проблему — спам аккаунты закрываются в течение дня-двух. Альтернатива — считать всех пользователей по умолчанию спамерами, и просить вводить капчу. Надеюсь до этого не дойдет. А спамеры как-то прямо вас тревожили на GitLab.com?