Мы с радостью объявляем о релизе GitLab 16.9 с GitLab Duo Chat, доступном для Premium пользователей SaaS и в инстансах с самостоятельным управлением! Также появилась возможность запрашивать изменения в мерж-реквесте без блокировки мержа, улучшенный интерфейс страницы переменных CI/CD, новые настройки для автоматической отмены конвейеров и многие другие фичи!
11 января 2024 года была опубликована информация об уязвимости в GitLab CE/EE, затрагивающая все версии с 16.1 до 16.1.6, 16.2 до 16.2.9, 16.3 до 16.3.7, 16.4 до 16.4.5, 16.5 до 16.5.6, 16.6 до 16.6.4 и 16.7 до 16.7.2. Данная уязвимость получила идентификатор CVE-2023-7028 и 7.5 баллов критичности по CVSS NVD - CVE-2023-7028 (nist.gov).
Она позволяла неавторизованным пользователям завладевать учетными записями пользователей, в том числе администраторов, без какого-либо вмешательства со стороны жертвы.
Уязвимость была вызвана ошибкой в том, как GitLab обрабатывал проверку электронной почты при сбросе пароля. Злоумышленник мог указать два адреса электронной почты при запросе на сброс пароля, и код сброса отправлялся на оба адреса. Это позволяло злоумышленнику сбросить пароль любого пользователя, даже если он не знал его текущий пароль.
Первый раз столкнулись с Git и не понимаете, что это такое?
Устали бездумно выполнять серию комманд чтобы закинуть свой проект на GitHub?
Хотите понять, чем отличается merge, rebase, push и pull?
Надоело видеть ошибку о non fast-forward merge и не понимать, что с этим делать?
Сейчас попробуем разобраться в этом всем.
Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.
Далее в нашей серии постов из трёх частей у нас новые фичи! Здесь я расскажу про пять относительно новых вещей в git, о которых вы могли не слышать, потому что ну почему вы?
Мы взглянем на:
Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.
В первом посте из этой короткой серии по Git я хотел начать с вещей, уже существующих какое-то время. При этом кажется, что многие люди о них не знают или не умеют ими пользоваться. В них нет ничего нового, но я нахожу их полезными и, возможно, не совсем освещёнными. Я просто хочу рассказать о:
git blame и git log с диапазонами строк;git blame с отслеживанием;git diff по словам вместо строк;
Мы с радостью объявляем о релизе GitLab 16.8 с поддержкой менеджера секретных ключей GCP, возможностью ускорения сборок с прокси зависимостей Maven, общим доступом к рабочим пространствам, новым представлением DevOps c бенчмарками на основе DORA и многими другими фичами!
Небольшой обзор систем контроля версий, альтернативных git, и основанных на математической теории. Речь пойдёт о двух системах распределённого контроля версий: Darcs, написанной на Haskell, и Pijul, написанной на Rust. Обе они сейчас активно развиваются и предлагают свои сетевые репозитории. Оказалось, что про них на Хабре толком нет ничего, тогда как про git образовался целый хаб. Поскольку я люблю и использую Haskell, я остановил свой выбор на Darcs, и вот, спустя два месяца непрерывной работы над библиотекой геометрической алгебры для hackage, я готов поделиться впечатлениями от её использования.
? Нативное решение Unity
В 2018 разработчики из Unity релизнули централизованное хранилище для итеративных обновлений движка и расширений Editor, которое получило название UPM - Unity Package Manager.
На этот раз мы с радостью объявляем о релизе GitLab 16.7 с фичей GitLab Duo Code Suggestions в общем доступе, бета-версией каталога CI/CD, новым детальным представлением графиков отчётов Insights, результатами сканирования SAST в представлении изменений мерж-реквеста и многими другими фичами!
Мы все были там: Вы работали над множеством изменений одновременно, некоторые из которых не имели ничего общего. Для удобства вы решили объединить все эти изменения в один коммит и на этом закончить. Но хотя это может показаться заманчивым, на самом деле это может привести к большим проблемам в дальнейшем. Большие коммиты могут:
Сегодня мы с радостью объявляем о релизе GitLab 16.6 с бета-версией GitLab Duo Chat, правилами соответствия требованиям на основе подтверждения мерж-реквестов, улучшенным механизмом ветвления, улучшенным интерфейсом пользователя для управления переменными CI/CD и многими другими фичами!
При построении релизного цикла приходится балансировать между двумя крайностями. С одной стороны, хочется по максимуму отлавливать баги и дотошно проверять каждый релиз. С другой — быстрее выпускать обновления и приносить клиентам больше пользы.
Мы в Mindbox долго решали это противоречие и, кажется, добились баланса: презентуем несколько релизов в день и каждый проходит несколько этапов проверки, чтобы баги не дошли до клиентов. Пайплайн удобен и для команды: больше сотни разработчиков работают одновременно и не блокируют действия друг друга, а обновления происходят автоматически.
О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.
Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Мы с радостью объявляем о релизе GitLab 16.5 с отчётами о соблюдении стандартов соответствия требованиям, правилами задания целевой ветки мерж-реквеста, возможностью завершать обсуждения по тикету, ускорением цепочек мерж-реквестов для полулинейной истории коммитов и многими другими фичами!
Сегодня мы с радостью объявляем о релизе GitLab 16.4 с настраиваемыми ролями, списком зависимостей для групп и подгрупп, локальному доступу к кластерам при помощи учётных данных GitLab, рабочими пространствами для приватных проектов и многими другими фичами!
Привет Хабр, меня зовут Дмитрий Несмеянов, я являюсь руководителем направления разработки ML-инфраструктуры "ЛОКО-банка".
Сегодня я хочу рассказать про DVC: инструмент, который многие, незаслуженно, обходят стороной. Была хорошая статья от Райффайзен Банк, в этой статье я постараюсь резюмировать мою и коллег экспертизу в работе с DVC.
DVC (Data Version Control) - это система версионирования датасетов и не только, которая является надстройкой над git. Если вы умеете работать с git, поздравляю, вы умеете работать с DVC. Кроме того, DVC позволяет логировать эксперименты, а также делать Auto-ML.
Из уст переводчика: инструмент puro совсем новый по меркам продуктовой разработки (первый релиз – октябрь 2022), но, по моему личному мнению, api его уже достаточно стабилизирован, а сам инструмент выражает искреннюю радость подходами. Большинство его текущих преимуществ (и выгодных отличий от fvm) я разбирал ранее в этом исчерпывающем материале – "Полное руководство по использованию FVM (Flutter Version Management) – жонглируйте версиями Flutter sdk в своих проектаx" – где вполне наглядно показано торжество puro...
В жизни разработчика рано или поздно наступает момент, когда проектов становится так много, что одной единственной (обычно это stable) версией flutter sdk уже не обойтись. В данной статье мы рассмотрим консольный инструмент fvm для управления версиями flutter sdk, ВСЕ имеющиеся в нём команды и пройдём путь от установки до использования в проекте.
В качестве бонусных аспектов я также уделил время на изучение Sidekick (графическая оболочка для fvm) и на разбор имеющихся аналогов (Puro – сильно уверен, что вы не слышали о таком инструменте).
Прошу к изучению ?
Это практическое дополнение к моей предыдущей статье, где я рассказывал, почему вам может быть интересен способ ведения версий с помощью бранчей. Сейчас же я хотел подробнее показать, как это можно реализовать на примере одного сценария. Естественно, я не могу показывать свои реальные юзер флоу, поэтому предположим, что у нас есть большой сценарий, за развитие которого вы отвечаете.
Сегодня мы с радостью объявляем о релизе GitLab 16.2 c совершенно новым редактором текста, палитрой команд, поддержкой подписей без ключей с Cosign, новым уровнем настроек для панели аналитики разработки и многими другими фичами!