Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа.


Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8




В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования!


Итак, в новой версии появились:


  • принципиально новый новый способ представления и работы с тикетами (issues);
  • слеш-команды (/command) для работы с тикетами;
  • возможность создавать шаблоны тикетов (в неограниченном количестве);
  • онлайн-среда разработки;
  • возможность разрешать конфликты мержа не выходя из GitLab;
  • настройка прав на пуш в ветку для отдельных участников и групп (только в ЕЕ);
  • … и много других фич, о которых мы тоже расскажем.

MVP этого месяца — Clement Ho. Спасибо ему за мерж-реквесты и отзывчивость в работе над задачами.


Доска тикетов (Issue Board)


Тикеты (issues) в GitLab — очень гибкий инструмент. Они могут содержать ссылки друг на друга, можно обозначить их приоритеты, можно отсортировать по популярности. Доска тикетов добавляет новый способ работы с ними.


Теперь можно настраивать рабочие процессы (workflows) и быстро получать информацию о состоянии тикетов. Всё это доступно на простой и приятной глазу доске, похожей на те, что используются в Канбане или Скраме.


Доска тикетов в GitLab 8.11


Доска создается для каждого проекта автоматически. По умолчанию все открытые тикеты формируют список-бэклог (Backlog), а все закрытые появляются в списке завершённых (Done list).


Добавляя новые списки, вы создаёте новые рабочие процессы. Принадлежность тикета к списку определяется меткой. При добавлении тикета в список к ней добавляется соответствующая метка, при удалении из списка — метка удаляется.


Если у вас раньше были метки вроде фронтенд, бэкенд и дизайн — самое время сделать из них списки. Тикеты появятся в них автоматически. И, конечно, тикет может принадлежать более чем одному списку.


Если хотите посмотреть на эту фичу в действии, загляните на доску GitLab CE версии 8.12.



Документация по доскам тикетов

Разрешение конфликтов при мерже


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


Разрешение конфликтов при мерже в GitLab 8.11


Когда мерж блокируется конфликтом, можно просто нажать кнопку "Resolve these conflicts" и перейти в интерфейс разрешения. Там можно выбрать нужные строки и закоммитить полученный результат.


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


Документация по разрешению конфликтов

Разрешения на работу с ветками для конкретных пользователей (только EE)


Теперь в Enterprise Edition можно настраивать разрешения на пуш или мерж в ветку не только для подгрупп пользователей (как developers или owners), но и для конкретных пользователей.


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


Разрешения на работу с ветками в GitLab 8.11


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


Документация по разрешениям на работу с ветками

«Закрытие» комментариев в мерж-реквестах.


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


Мы добавили возможность отметить комментарий или целую ветку как обработанную и закрыть её.


Закрытие обсуждений в GitLab 8.11


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


Переход к следующему открытому обсуждению в GitLab 8.11


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

Схемы конвейеров.


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


Схемы конвейеров в GitLab 8.11


Просто кликните на конвейере на странице мерж-реквеста или в списке конвейеров. Вы увидите схему этого конвейера с отображением выполненных, проваленных, активных и ожидающих сборок.


Шаблоны тикетов и мерж-реквестов.


Возможность стандартизировать тикеты и мерж-реквесты с помощью шаблонов уже была в GitLab Enterprise Edition. Начиная с GitLab 8.11 шаблонов может быть много — например, один для ошибок, а другой для предложений. А сама возможность есть во всех версиях: GitLab.com, GitLab CE/EE.


Шаблоны пишутся в разметке Markdown и лежат в вашем репозитории соответственно в папках .gitlab/issue_templates и .gitlab/merge_request_templates:


Шаблоны тикетов и мерж-реквестов в GitLab 8.11


Цель этой фичи — улучшить внешний вид и полноту предложений, сообщений об ошибках и мерж-реквестов.


Документация по шаблонам

Слеш-команды


Теперь в GitLab есть слеш-команды (/command) — так же, как в IRC, HipChat, Mattermost или Slack. Они позволяют менять метки, назначать исполнителей, подписываться и отписываться от тикетов и делать многое другое — быстро и не отрывая рук от клавиатуры. Команды работают в описании тикета или мерж-реквеста, а также в комментариях.


Как ими пользоваться:


  1. Вы вводите текст, содержащий команду (с клавиатуры, из шаблона, через API, как угодно).
  2. Подтверждаете отправку комментария, сохранение тикета или реквеста.
  3. Команды выполняются и больше не показываются в тексте. Если комментарий состоял только из команд, он будет выполнен, но не опубликован.

Слеш-команды в комментариях в GitLab 8.11


Можно использовать слеш-команды даже при создании нового тикета или реквеста:


Слеш-команды при создании тикета в GitLab 8.11


Если последовательно указать несколько команд, то все они будут выполнены.


Несколько идей, как можно использовать слеш-команды:


  • В письме в ответ на оповещение из тикета или мерж-реквеста (текст письма становится комментарием).
  • В шаблоне тикета или мерж-реквеста.
  • Через notes API.

Мы сами с нетерпением ждём ваших рассказов о том, какие ещё способы использования вы изобретёте.


Документация по слеш-командам

Интеграция с Koding


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


Начиная с версии 8.11 GitLab поддерживает интеграцию с Koding. Теперь одним нажатием кнопки можно выкачать проект целиком или отдельный мерж-реквест и открыть его в полноценной облачной IDE. (обратите внимание, что на GitLab.com интеграция с Koding пока не добавлена).


Включите поддержку Koding в Admin > Application settings


Koding, an integrated IDE in GitLab 8.11


Настройте Koding для работы с вашим проектом:


Koding, an integrated IDE in GitLab 8.11


Koding, an integrated IDE in GitLab 8.11


И все! Теперь вы можете быстро выкачать любой мерж-реквест, ветку и коммит проекта в полноценную IDE.


Koding, an integrated IDE in GitLab 8.11


Мы подготовили небольшое видео, показывающее процесс работы связки Koding + GitLab:



Для того, чтобы узнать больше о Koding в GitLab, обратитесь к нашей документации.


Конвейеры в мерж-реквестах


Теперь конвейеры отображаются в мерж-реквестах:


Pipelines in merge requests in GitLab 8.11


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


Отображение статуса развертывания для мерж-реквестов


Теперь вы можете указывать URL для своих сред развертывания (environments):


Set the URL of any environment in GitLab 8.11


Благодаря этому GitLab показывает статус развертывания для мерж-реквестов в случаях, когда развертывание происходит автоматически при мерже:


See deploy status in merge request in GitLab 8.11


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


Веб-хуки для конвейеров (pipelines)


Для упрощения интеграции с конвейерами GitLab мы добавили веб-хуки для них. Они срабатывают при создании, запуске или завершении работы конвейера.


Для того, чтобы добавить веб-хук, выберите Webhooks в меню Settings вашего проекта.


Подсветка и скрытие кода


Теперь редактор GitLab поддерживает подсветку и позволяет скрывать блоки кода.


Code highlighting in GitLab 8.11


Ссылки на мерж-реквесты при пуше


Теперь при пуше на GitLab появляются ссылки на создание мерж-реквеста, а также на все мерж-реквесты, имеющие отношение к текущему.


Merge request links when pushing in GitLab 8.11


Значок покрытия тестами (test coverage)


Появилась возможность создавать значки, показывающие покрытие тестами вашего проекта:


Coverage Badge in GitLab 8.11


Если вы не использовали отображение покрытия в GitLab, подключите его в настройках конвейеров: pipelines/settings.


Документация по значкам покрытия тестами

Временные ограничения на доступ к проекту


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


Это упрощает работу с правами доступа для временных членов команды.


Перемещение проектов между шардами (только EE)


В GitLab 8.10 были добавлены множественные точки монтирования (mount points).


В GitLab 8.11 появилась возможность перемещать проекты между шардами (shards) при помощи команды rake. Эта функциональность не предполагается для частого использования, однако она может оказаться полезной в случаях, когда вы хотите протестировать новый шард или переместить часто используемый проект на хранилище с быстрым доступом.


Улучшения производительности


В данном релизе был введен ряд изменений направленных на повышение производительности — мерж-реквесты и их диффы стали еще быстрее! Ниже приведены графики, показывающие разницу в производительности после развертывания GitLab 8.11 RC2 на GitLab.com (падение в производительности попадает на развертывание).


Время загрузки диффов для мерж-реквестов:


Performance improvements in GitLab 8.11


Количество выполненных SQL-запросов при отображении диффов:


Performance improvements in GitLab 8.11


Время, потраченное на выполнение SQL-запросов при отображении диффов:


Performance improvements in GitLab 8.11


Также значительно повысилась производительность конвейеров:


Performance improvements in GitLab 8.11


Ниже приведен детальный список проведенных улучшений и соответствующих мерж-реквестов:


Улучшения


  • Улучшен процесс проверки на возможность пользователю просматривать несколько тикетов: !5370
  • Улучшена процесс проверки максимального уровня доступа пользователя: !5412
  • Уменьшено количество SQL-запросов для отображения CI графиков: !5502
  • Добавлены улучшения для работы GitLab’а с Git, направленные на уменьшение количества используемых команд и более быструю сортировку номеров версий: !5536, !5375
  • Информация об авторах коммитов теперь кешируется для каждой Sidekiq-транзакции во избежание дополнительных выборок: !5537
  • Уменьшено количество запросов, используемых для отображения диффов мерж-реквестов: !5551
  • Улучшена итерация по наборам диффов: !5564
  • Повышена производительность методов, зависящих исключительно от статистики диффов: !5568
  • Повышена производительность создания диффов путем удаления излишних проверок на текстовые блобы: !5575
  • Удалены ненужные вызовы методов при создании диффов: !5591
  • Улучшена проверка на активность diff note: !5597
  • Улучшен процесс создания ссылок на трекер тикетов: !5608
  • Повышена производительность парсинга ссылок в документах Markdown: !5629
  • Повышена производительность синтаксической подсветки блоков кода в документах Markdown: !5643
  • Улучшен процесс генерации ключей кеша для документов Markdown: !5715
  • Улучшен процесс сортировки тегов Git: !5723
  • Удалены триграммные индексы для таблицы ci_runners (только для PostgreSQL): !5755
  • Удалены выборки коммитов в DiffHelper: !5756
  • Удалены 45 избыточных индексов для баз данных: !5759
  • Обратно добавлено кеширование todo-счетчиков: !5789
  • Уменьшено количество проектов, используемых в запросах на получение списка todo: !5791
  • Более не отображаются SVG-изображения размером более 2 мегабайт, благодаря чему уменьшено время загрузки и использование памяти: !5794
  • Решена проблема с утечкой памяти в sanitization-фильтре Markdown: !5808
  • Изменено отображение выпадающего меню, показывающего список проектов, в которые можно переместить тикет — теперь используется постраничный вывод вместо отображения полного списка: !5828, !5686
  • Удалены вызовы методов, ответственных за поиск ненужных блобов Git: !5848
  • Добавлена асинхронная загрузка выпадающих меню для веток в диалогах cherry pick и revert: !5607
  • Улучшены запросы, используемые для отметки todo как завершенных: !5832
  • Проведен апдейт gitlab_git до версии 10.4.7 для использования улучшений, появившихся в этой версии библиотеки: !5851
  • Улучшены проверки доступа Git в Enterprise Edition: !647
  • Удален ненужный индекс таблицы geo_nodes: !639
  • Ace Editor теперь загружается только по необходимости, что уменьшает размер используемого JavaScript почти на 100 килобайт: !4914

Новые фичи


  • Sidekiq теперь кеширует некоторые объекты транзакций. Эта опция включена по умолчанию, ее можно отключить через переменную окружения: !5054
  • Теперь GitLab может использовать ruby-prof при обработке запросов, сохраняя данные профилировки на диск для дальнейшего просмотра. Для использования этой фичи нужно определить токен в заголовке: !5281
  • Добавлена возможность отслеживания кастомных событий с помощью GitLab Performance Monitoring. Например, количество пушей, форков проектов и т. д.: !5830

Инструментирование


  • Проведено инструментирование Nokogiri: !5470
  • Уменьшена ненужная нагрузка на инструментирование вызовов методов: !5550
  • Проведено инструментирование класса Repository: !5621
  • Проведено инструментирование Gitlab::Highlight: !5644
  • Проведено повторное интсрументирование Project.visible_to_user: !5793

GitLab Mattermost 3.3


GitLab 8.11 поставляется с Mattermost 3.3, открытым аналогом Slack.


В Mattermost 3.3 добавлены локализации на китайский, корейский и голландский языки, бот на Go,
возможность помечать (flag) посты, упоминания вида @here и многое другое.


Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее.


Поддержка Redis Sentinel


В GitLab теперь еть экспериментальная поддержка Redis Sentinel.


Все подробности в документации

Прочие изменения


Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в Changelog.


Upgrade-барометр


Обновление до GitLab 8.11 потребует даунтайма из-за миграций баз данных


Даунтайм для сайта GitLab.com (самый крупный из известных нам инстансов GitLab) составил 15-30 минут. В зависимости от количества данных на вашем инстансе ваш даунтайм может быть меньше.


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


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


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


Устаревание (deprecation) Ruby 2.1


С этим релизом мы обновили Ruby до версии 2.3.


Для ручных установок мы настоятельно рекомендуем вам обновить Ruby до 2.3. Установки GitLab, сделанные через Omnibus, автоматически будут использовать Ruby 2.3.


Поддержка Ruby 2.1 и 2.2 будет полностью прекращена в GitLab версии 8.13.


Для тех, кто обновился раньше остальных


Если вы обновились до 8.11 сразу после релиза и в процессе reconfigure получили ошибку undefined method merge! for nil:NilClass, то скачайте более новый пакет с младшей версией .1: 8.11.0-ce.1.


Просто запустите apt-get update and apt-get install gitlab-ce / apt-get install gitlab-ee, и всё должно починиться само.


Форсированная двухфакторная аутентификация при использоваии GitLab API и Git поверх HTTP


Если у вас включена двухфакторная аутентификация и вы пытаетесь получить API-токен через метод /sessions или Resource Owner Password Credentials flow provided в OAuth2, то вы не сможете залогиниться. Для успешного логина в этих случаях вам нужно будет использовать Personal Access Token.


Подробнее о personal access tokens

Реиндексирование Elasticsearch (только для EE)


Мы изменили структуру индексов Elasticsearch и теперь они используют взаимоотношения типа «родитель-ребенок». Это повышает производительность, но требует полной перестройки всех индексов Elasticsearch. После обновления до 8.11 вам надо будет вручную удалить старые индексы и построить новые.


Для удаления старых индексов сделайте вот такой запрос к Elasticsearch:


curl -XDELETE 'http://localhost:9200/_all/'

Для перестройки индексов выполните действия описанные в документации по интеграции с Elasticsearch


Внимание Описанное выше применимо только если вы обновляетесь с предыдущей версии (8.10). Если вы обновляетесь с более ранних версий, проверьте разделы «Upgrade-барометр» для всех промежуточных версий.


Если вы обновляетесь с версии GitLab, меньшей, чем 8.0 и при этом у вас включен CI, вам нужно сначала обновиться до 8.0.


По умолчанию в процессе обновления все пакеты Omnibus будут остановлены, потом будут прогнаны все их миграции, и только потом они будут запущены снова. Это поведение не зависит от «размера» обновления. Изменить это поведение можно, создав файл /etc/gitlab/skip-auto-migrations.


Установка


Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел: https://about.gitlab.com/installation/


Обновление


Инструкции по обновлению: https://about.gitlab.com/update/


Enterprise Edition


GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп. Подробную информацию можно посмотреть в описании GitLab EE.


GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут.


Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.


P.S. Если будете обновляться, обновляйтесь сразу на 8.11.2


P.P.S. Над переводом работали chebureque, nick_volynkin и @sgnl_0

Поделиться с друзьями
-->

Комментарии (33)


  1. VYakushev
    26.08.2016 19:57
    +2

    Так много, что аж страшно…


  1. Dmitrych61
    26.08.2016 20:10

    Тоже было страшно… у нас «ручная установка» на CentOS 7.2, обновил на тестовом окружении, пока стабильно работает весь заявленный функционал. Один момент — лучше сразу обновить Ruby до 2.3, переставить бандлер ну и обновить все гемы, как обычно. В остальном обновление из сорцов проходит без проблем, в прочем, как всегда. Спасибо команде GitLab.


    1. nem
      26.08.2016 20:15
      +1

      отчего не переедете на установку через пакеты?


      1. Dmitrych61
        26.08.2016 20:17

        Это в планах, пугает postgresql, нет опыта работы с ним. Других причин нет, скоро переберемся.


  1. nick_volynkin
    26.08.2016 20:16
    +3

    Про слеш-команды: фактически, GitLab предлагает ещё один инструмент для хранения конфигурации в виде кода (например, в шаблонах со слеш-командами). Только это конфигурация не инфраструктуры (для этого достаточно инструментов), а рабочего процесса. И конфигурация рабочего процесса по проекту хранится и версионируется вместе с кодом этого проекта, что выглядит весьма удобно.


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


  1. hermit931
    26.08.2016 20:28

    Жирненько :)


  1. Pilat
    26.08.2016 21:05

    Есть ли возможность переносить issue между проектами или связывать issue в разных проектах?


    1. nem
      26.08.2016 21:15
      +1

      Да: https://about.gitlab.com/2016/04/20/feature-highlight-move-issues/


      Насчет второго — кажется что да, но не уверен


    1. nick_volynkin
      27.08.2016 09:47

      Вы можете в комментарии или описании тикета написать gitlab-org/gitlab-ce#123 и это будет рабочая ссылка на тикет #123 в репозитории gitlab-org/gitlab-ce.


      1. Fortop
        27.08.2016 13:41

        Вы же понимаете что это палиатив, а не связь?


        1. nick_volynkin
          27.08.2016 17:12

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


        1. nick_volynkin
          28.08.2016 17:35

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


          1. Fortop
            30.08.2016 15:42

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

            Формирование ссылки на связанную задачу это, конечно, лучше чем ничего


            1. nick_volynkin
              30.08.2016 16:43
              +2

              Я нашёл пару предложений на функционал, который вы хотите (да и я бы не отказался):



              Там можно проголосовать и/или написать о своих пожеланиях. А пока, насколько я заметил, сами сотрудники гитлаба составляют списки (синтаксис списка: "- [x]"), отмечают по мере выполнения, ну и просто договариваются не закрывать задачу, если не везде галочки.


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


      1. Pilat
        27.08.2016 14:35

        Могу, конечно, но как потом это использовать? Именно из-за таких проблем сейчас приходится держать монстра-Jira


        1. nick_volynkin
          27.08.2016 17:09

          Да, я и не утверждал, что это полноценное решение. Но это наибольшее приближение, которое получилось найти.


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


          1. Pilat
            27.08.2016 17:13

            Но это же типовая проблема — мелкие проекты, слабосвязанные. REST запрос из одного в другой — и проблема сразу у обоих, одна на всех общая и две узкоспециализированные. Всё идёт от того, что GitLab никак не определятся — они git репозиторий с фичами, или программа управления разработкой и поддержкой со встроенным репозиторием.


            1. nick_volynkin
              28.08.2016 17:33

              Проверил только что — упоминание задачи из одного проекта в задаче другого проекта создаёт запись в логе и обратную ссылку в первой. Пример тут.


              Насчёт определения между репозиторием и программой управления разработкой: мне кажется, всё-таки в центре стоит репозиторий. Это крупная и неотключаемая фича, а многое другое (issues, wiki, builds, merge requests, snippets… ) можно включать и отключать по желанию. Хотя можно и саппорт из него сделать, по примеру их собственного репозитория для саппорта.


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


              1. Pilat
                28.08.2016 23:44

                Да, получается. Не очень красиво, но работает. Выгоднее оставлять ссылку на другое issue в теле вопроса — получается заметней.


  1. SlavikF
    26.08.2016 21:41

    Issue board — штука нужная. Но в этой версии она очень примитивная:
    — Нет возможности приоритезации issues в колонке перетаскиванием выше или ниже. Вроде бы можно это делать через создание prioritization labels, но это выглядит настолько дремуче: у всех других систем это просто работает перетаскиванием вверх / вниз
    — Колонка DONE прибита гвоздями, и никак её не убрать. Зачем мне смотреть на миллион issue, которые уже закрыты? Они мне не нужны! Вроде бы колонка нужна, чтобы туда можно было бы перетащить, и таким образом закрыть issue, но можно было бы придумать что-то более элегантное.

    Надеюсь, что со временем допилят…


    1. nem
      26.08.2016 21:54
      +1

      Все так. Это только первая итерация. Вот здесь планы по развитию: https://gitlab.com/gitlab-org/gitlab-ce/issues/21365


  1. pOmelchenko
    26.08.2016 22:14

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

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


    1. crackedmind
      26.08.2016 22:19

      В планах такого не видел. Но код открыт же, можно дописать не достающий функционал…


    1. SlavikF
      26.08.2016 22:55

      Есть вот такая фишка, которая почти доделана, но не была включена в эту версию, потому что немного не допилена:
      https://gitlab.com/gitlab-org/gitlab-ce/issues/3243 New Issue by email

      Но я не совсем понял, в какой проект будет попадать вновь созданные issue. И похоже там есть некоторые требования по форматированию emails.

      Не сразу понял, про какого исуса у вас написано… Наверное, это не самый удачный перевод «Issue» на русский. Может «задача», или «тикет»?


      1. pOmelchenko
        27.08.2016 13:26

        Да, простите – задачи конечно же.


  1. dim_s
    26.08.2016 22:20
    +1

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


  1. Moxa
    27.08.2016 00:45
    -1

    а есть счетчик коммитов, количество дней подряд, как раньше на гитхабе?


  1. kalyukdo
    28.08.2016 12:03

    есть один недостаток, нет возможности объединить 2 репозитория в 1 проект, така это часто бывает есть фронт(spa) и бэк и соответственно репы разные, общую картину не увидеть


    1. nem
      28.08.2016 12:04

      А чем вам группы не подходят как способ объединения?


      1. kalyukdo
        28.08.2016 12:31

        Большое спасибо за наводку, пошел читать мануал


      1. kalyukdo
        28.08.2016 12:51

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


        1. nem
          29.08.2016 16:17
          +1

          Да, поддержка issue board для групп еще не реализована: https://gitlab.com/gitlab-org/gitlab-ee/issues/928


  1. voe
    28.08.2016 17:06

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