aionin Jan 8 2018 at 18:39

Вышел GitLab 10.3: статическое тестирование безопасности приложений и тестирование производительности в браузере

14 min

8.6K

Open source*Git*Version control systems*Build automation*

Translation

+16

Comments 14

UFO just landed and posted this here

aionin Jan 9 2018 at 15:03

Скорее всего нет, насколько можно понять CEO

Negash Jan 9 2018 at 00:00

А кто-то дружил auto DevOps или k8s с моно репозиторием (20+ сервисов)?

aionin Jan 9 2018 at 15:19

Надо сказать, что Gitlab AutoDevOps пока находится в состоянии beta. Поэтому официальных пресс-релизов об успешном внедрении в пром и интеграции с k8s у вендора нет. Но будут. Дайте время.

nick_volynkin Jan 17 2018 at 08:11

Я не сотрудник GitLab и не отслеживаю планы разработки. Но, как обычный пользователь, сильно сомневаюсь, что когда-либо будет автодевопс для конкретного монолитного репозитория. Это же шаблоны, они рассчитаны на типовое приложение Ruby, типовое приложение Python и т.п.

Однако вы сами можете написать .gitlab-ci.yml под любое приложение, хоть с десятками сервисов.

DjPhoeniX Jan 9 2018 at 01:52

Pages на subgroups когда завезут? Ещё в 10.0/10.1 обещали.

aionin Jan 9 2018 at 15:06

Ветка запроса этой функциональности доступна по ссылке
Точных сроков нет, но, возможно, фича будет реализована в течение полугода.

namee Jan 9 2018 at 14:56

А могли бы вы добавить в список комитов столбец с порядковым номером? Очень удобро для релизов дабы точно знать с какой точки сборка. Наверняка в базе ведь есть эта инфа.

aionin Jan 9 2018 at 16:07

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

namee Jan 10 2018 at 09:36

GitLab как рабочее офисное хранилище полностью устраивает. Но к сожалению пользоваться ресурсами поддержки и документации ужасно неудобно. Не ориентированы они на «средний класс».

Может я слишком размыто описал. Так вот…
У каждого комита хотелось бы видеть порядковый номер, который автоматически присваивается по мере их поступления в хранилище.

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

Вполне возможно что это как-то делается через события / прочее. Дописывается в комментарии / ещё куда-то.

Система в этом плане слишком сложна а времени глубоко копать её нет.
Спасибо!

zzzzzzerg Jan 13 2018 at 15:54

Иметь номера комитов против идеологии git-a.

Думаю вам будет интересно:
softwareengineering.stackexchange.com/questions/205411/why-does-git-use-hashes-instead-of-revision-numbers

namee Jan 15 2018 at 10:47

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

nick_volynkin Jan 17 2018 at 08:03

Порядковые номера не будут работать, потому что коммиты не делаются строго последовательно. Обычно разработчики делают коммиты в ветки для реализуемых ими задач, а потом сливают эти ветки в основную (например, master). Разработка идёт одновременно и порядковые номера не будут иметь смысла.

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

Чтобы удобно и понятно искать, присваивайте коммитам понятные и подробные описания. Подробнее об этом:

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

git tag -m'Version 1.0' 1.0

Теперь, когда собираете релиз, используйте тег вместо хеша коммита.

nick_volynkin Jan 17 2018 at 08:06

Пожалуйста, расскажите подробнее, что вы хотите сделать с помощью поддержки и документации и что именно там неудобно?

Show the best of all time