Комментарии 10
Мы недавно перешли на
concurrent = 2
так как много ресурсов простаивает без дела когда только одна джоба разрешена.
Согласен, если ресурсы системы позволяют и это не приводит к замедлению общего выполнения, то можно спокойно увеличить на тех решениях, где собирается один проект.
Если же проектов несколько, то есть вероятность, что джобы будут друг другу мешать.
Например, если secure files одного проекта будут перезаписаны другим. Справиться с этим не трудно, но все-таки стоит учитывать.
C ума сойти, кажется, впервые за последнюю пару-тройку лет лет я вижу запятую между частями сложносочинённого предложения, которым открывается статья на хабре! Супер.
А что делать, если есть несколько проектов, и у них конфликтующие зависимости? Ведь их нельзя тогда пускать на один и тот же физический раннер. Есть ли у Apple технология управления окружениями, типа docker? Или предполагается что тогда надо покупать ещё один мак :-)
Интересный вопрос, можете привести пример такого конфликта?
Да, конечно, из недавнего: есть десяток проектов и несколько раннеров. Один из проектов где-то в глубине своиз 3rd-party скриптов обновляет pip до свежей версии на раннере, в итоге часть других проектов (которые не используют venv) ломаются, потому что он не разрешает больше ставить пакеты без venv. Происходит это, естественно, в пятницу вечером.
Мы используем Jenkins, и у него есть разнообразные плагины, например он может запускать VM как раннер по запросу (в т.ч. из темплейта), но с приходом чипов M все гипервизоры типа VmWare превратились в тыкву, и теперь все команды делят bare-metal ноды, со всеми вытекающими приколами. И вот всё думаю, как бы их изолировать по-красивому. В Linux сборках такой проблемы нет - мы давно уже принудительно заставляем использовать докер, не даём прав на запись куда не нужно, не даём запускать :latest теги и т.п. Конечно есть ещё 999 других способов поломать сборку, но они хотя бы не мешают друг другу.
Разумеется, можно попросить разработчиков уважать друг друга, делать всё правилньо, думать об изоляции и общем использовании, но когда много разных проектов, 3rd-party, legacy и прочее - тут это не так работает, к сожалению.
Попробуйте как-то через bash переменные для проблемного проекта выставить чтобы pip обновлялся и смотрелся не в системный, а для этого проекта отдельный путь или что-то подобное. Например, у нас постоянно были глюки с руби, что подхватывалась не та версия, в итоге мы просто на старте джобы зафорсили нужную версию выставив ее вначале поиска для bash
before_script:
- export PATH="/opt/homebrew/opt/ruby@3.1/bin:$PATH"Да, спасибо, мы примерно так и поправили. Но вопрос у меня риторический, я написал об этом в последнем абзаце: хотелось бы предотвратить подобные вещи, а не с горящей пятой точкой чинить в пятницу вечером, когда у кого-то из команд в Pull-request, который открыли вдруг оказалось что-то типа в CI:
export TPM_DIR=".cache"
...
rm -rf $HOME/$TMP_DIR, который потом ещё пару раз перезапустили потому что «пайплайн почему-то зафейлился» или PR обновили пару раз (нашли опечатки в комментариях), который в итоге ещё на нескольких машинах побывал из-за этого.
Причем важнее даже изолировать команды/проекты друг от друга, одно дело когда твоя сборка поломалась из-за свежих изменений, а совсем другое - когда есть вероятность что она вдруг не работает из-за какого-то рандомного чела из другого здания.
Пока что, видимо - предполагается что надо покупать свои маки на команду или проект, что сложно назвать нормальным решением. Меня не покидает ощущение, что ну не может быть всё так плохо у Apple с автоматизацией - должно быть какое-то нормальное корпоративное/промышленное/фирменное решение.
У нас на CI (одна машина и всего один ранер) три проекта, параллельные джобы, переиспользование запущенных стимуляторов для тестов и куча другой магии для ускорения сборок и тестов. Пока не сталкивались с конфликтами между проектами)
Были конфликты в gem версиях, один проект один cocoapods/fastlane использовал, другой другие версии, но мы привязали гемы к каждому проекту через
bundle config set --local path 'vendor/bundle'
bundle installXcode версия также легко переключается на лету на каждой джобе через https://docs.fastlane.tools/actions/xcodes/. Мы уже несколько джоб настроили на Xcode 16 beta и iOS 18 beta, и наши тесты выявили баг в SFSafariViewController которые перестал работать.
Но некоторые тулы приходится держать глобальными (Carthage, Crowdin) так как другой возможности нет.
CI/CD заказывали? Или простое, но подробное руководство по настройке CI/CD под несколько iOS проектов