Pull to refresh

Comments 33

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

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

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

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


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

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

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

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

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

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

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

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

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



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


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

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

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


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

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

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


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


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

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

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

Так-то, у меня уже есть мелкая мечта по внедрении данного инструмента в нашей конторе =)
В планах такого не видел. Но код открыт же, можно дописать не достающий функционал…
Есть вот такая фишка, которая почти доделана, но не была включена в эту версию, потому что немного не допилена:
https://gitlab.com/gitlab-org/gitlab-ce/issues/3243 New Issue by email

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

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

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

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

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

Большое спасибо за наводку, пошел читать мануал
Изучил вопрос. но там нет канбана, группы дают лишь объединить в проект задачи. но управлять проектом из нескольких репозиториев нет возможности
а есть какие ни будь планы по разыитию вики? а то даже распечатать нормально нельзя через веб, а хочется не только печатать но и экспортировать в обшие форматы.
Sign up to leave a comment.