LINUX.ORG.RU

Cirrus CI прекратил работу после перехода команды Cirrus Labs в OpenAI

 cirrus, cirrus ci, ,


0

1

Сервис непрерывной интеграции Cirrus CI прекратил выполнение задач 1 июня 2026 года. Решение связано с тем, что команда Cirrus Labs переходит в OpenAI и присоединяется к направлению Agent Infrastructure. В официальном объявлении Cirrus Labs указано, что компания больше не принимает новых клиентов для Cirrus Runners, поддержит существующие контракты до окончания их срока, а сам Cirrus CI будет закрыт с понедельника, 1 июня 2026 года.

Cirrus Labs работала около девяти лет и развивала инструменты для CI/CD, сборочных окружений и виртуализации. В 2018 году команда запустила SaaS CI/CD-сервис с поддержкой Linux, Windows и macOS, а позднее выпустила Tart — популярный инструмент виртуализации macOS на Apple Silicon, а также Vetu и Orchard.

Кого это затронуло

На GitHub уже появились задачи по миграции у крупных open source-проектов. Например, runc открыл задачу «Migrate Cirrus CI jobs to GHA before June 1st» и прямо указал на необходимость переноса задач в GitHub Actions.

В SciPy закрытие Cirrus CI связали с риском потери GPU runner-задач и отметили, что проект не единственный оказался в такой ситуации.

У fish shell Cirrus CI использовался для проверок FreeBSD, Alpine и старых версий Ubuntu; без замены проект рисковал потерять эти CI-прогоны.

Закрытие Cirrus CI стало не просто уходом ещё одного CI-сервиса с рынка, а событием для FOSS-экосистемы. Особенно пострадали проекты, которые использовали Cirrus не как очередной Linux-runner, а как удобную площадку для кроссплатформенных сборок, нестандартных окружений и macOS-виртуализации.

Что именно меняется

  • Cirrus CI закрыт. Репозитории, использовавшие .cirrus.yml, больше не могут рассчитывать на выполнение задач в Cirrus CI после 1 июня 2026 года. Для проектов это означает необходимость переноса пайплайнов на GitHub Actions, GitLab CI, Buildkite, Jenkins, CircleCI или другую платформу.

  • Проектам нужно переносить CI вручную. Закрытие Cirrus CI не сводится к замене одного раннера на другой: конфигурации .cirrus.yml, образы, матрицы сборки и платформенные проверки придётся переносить на новую CI-систему. Это особенно чувствительно для проектов, которые использовали Cirrus ради нестандартных окружений, например FreeBSD, Alpine, старых Ubuntu, GPU-задач или macOS-инфраструктуры.

  • Cirrus Runners больше не принимает новых клиентов. Сервис выделенных раннеров не закрывается одномоментно для всех, но новые подключения прекращены, а существующие клиенты будут обслуживаться только до конца уже заключённых контрактов.

  • Tart, Vetu и Orchard переводятся на более свободную лицензию. Cirrus Labs заявила, что её source-available-инструменты, включая Tart, Vetu и Orchard, будут перелицензированы под более разрешительную лицензию, а лицензионные платежи за них уже отменены. Это сохраняет код для сообщества, но не гарантирует прежний уровень сопровождения со стороны исходной команды.

>>> Источник

★★★★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 3)

Кто все эти люди (не перестаю задавать этот вопрос с момента появления LLM)

kaldeon ★★
()

По хорошему, у каждого проекта должны быть вот такие (или типа того)

стойки, нафаршированные железом и ОС которые поддерживаются, а не зависеть от хрен пойми кого. А чтобы это было, нужна хоть какая-то монетизация что к сожалению в отношении СПО воспринимается в штыки, поэтому FOSS почти весь, завязан по гланды на SaaS, к котрому есть только ямловый интерфейс, и при отвале SaaS отваливается половина FOSS, как минимум релизы и тестирование, тупо неначем делать.

Внешние SaaS норм как дополнение, движение экономики все дела, но как фундамент, херовая затея, но вынужденная.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Cirrus CI закрыт. Репозитории, использовавшие .cirrus.yml, больше не могут рассчитывать на выполнение задач в Cirrus CI после 1 июня 2026 года.

zstd/dev/.cirrus.yml.

dataman ★★★★★
()
Ответ на: комментарий от kaldeon

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

unclestephen ★★★★★
() автор топика

позднее выпустила Tart

а также Vetu и Orchard

Кто все эти люди?!

использовался для проверок FreeBSD, Alpine и старых версий Ubuntu

Усраться потеря конечно :-D

zabbal ★★★★☆
()
Ответ на: комментарий от LINUX-ORG-RU

Вот такие стойки, свои ОС, свои инструменты софтовые, свои протоколы, свои днс сервера. В идеале свои независимые сети альтернативного интернета, неподвластные государствам.

А оплачивать все это видимо должны юзера.

LightDiver ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

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

Для ОС вроде OpenBSD я ещё могу понять такой подход. Но для «каждого проекта»? Глупость же. Обычный проект можно тестировать на разных сочетаниях ОС и архитектур, и это всё прекрасно воспроизводится в виртуальных машинах, а то и в контейнерах. А значит прекрасно тестируется в облаке.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от LightDiver

Ты сейчас используешь тактику доведения чужой мысли до полного абсурда, а затем делаешь из него (абсурда) вывод. Серьёзно? :D Я тоже так могу, и свести твои претензии к тонким клиентам, мол зачем вообще дома иметь что-то кроме тонкого клиента до серверов дядь?

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

Понятное дело что если тебе надо сделать билд софтины для запуска её на «Ломоносове» и оттестировать, ты приобретать суперкомпьютер не будешь и не сможешь, а купишь его вычислительное время в аренду. Во всём есть компромисс, но любая толика самодостаточности это благо, на это можно смотреть в зависимости от ситуации скептически, мол зачем тебе покупать целый мак, если нужно под него билдить релиз раз в три года. Но яро топить против самодостаточности, естественного процесса разработки, ну такое себе.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от vbr

это всё прекрасно воспроизводится в виртуальных машинах, а то и в контейнерах. А значит прекрасно тестируется в облаке.

Если все это прекрансо воспроизводится в виртуальных машинах/контейнерах, то зачем облако-то? На локальной машине разработчика можно всё это хозяйство развернуть. Пусть не одновременно, по пять-шесть контейнеров за раз, но вполне протестируется за ночь.

Как говорил Столлман, «не бывает облаков, бывает компьютер чужого дяди».

vitus ★★
()
Ответ на: комментарий от LightDiver

свои независимые сети альтернативного интернета, неподвластные государствам

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

firkax ★★★★★
()
Ответ на: комментарий от Zhbert

Узнал о проекте из новости о его закрытии.

Судя по списку пострадавших, этот проект просто работал, не создавая проблем, поэтому в новости не попадал.

question4 ★★★★★
()
Ответ на: комментарий от firkax

Так это вечный путь борьбы. Без борьбы тебе бы и из дома без разрешения нельзя было бы выйти. А то и дышать.

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

LightDiver ★★★★★
()
Ответ на: комментарий от vitus

Можно и так, но это неудобно. А если речь о других архитектурах, например ARM, тут эмуляция это прям очень медленно. А облако это очень удобно и очень дёшево. Зачастую вообще - бесплатно.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от vbr

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

Ну так да, таким проектам как openbsd (на картинке) нужен фарш, огромному количеству других, хватить 1 машинки с локальным CI на виртуалках. Потребности разные же. Суть одна. Возможность продолжать разработку независимо от отвала SaaS, где последний использовать там и тогда когда это выгодно. Я про то что CI обычно начинается и заканчивается на подправленном ямл шаблоне и всё. Локально порой вообще никак и ничего не собирается, кроме как для галочки и случись чуть что во вне, у тебя локально всё кря. Что плохого и глупого в том чтобы иметь запасной вариант, базовой необходимости, ты можешь на компе в котором код редактируешь вообще не иметь инструментов по его сборке и запуске и дрыгать всё на билд сервере постороннего лица, но глупостью ли будет как минимум желание обладать локальными инструментами сборки? Тут тоже самое. SaaS может значительно расширить возможности, но когда он целиком заменяет это уже риски, последствия которых прямым текстом описаны в шапке новости.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LightDiver

Никакой борьбы тут нет, это просто неизбежный факт. Вся деятельность на территории государства подконтрольна государству (если только оно не в состоянии развала).

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

firkax ★★★★★
()
Ответ на: комментарий от vitus

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

legolegs ★★★★★
()
Ответ на: комментарий от LightDiver

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

Morin ★★★★★
()
Ответ на: комментарий от vbr

А что арм? Берешь свой старый смартфон и гоняешь всё что хочешь.

BruteForce ★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Суть одна. Возможность продолжать разработку независимо от отвала SaaS, где последний использовать там и тогда когда это выгодно.

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

Облако облаку рознь. Если от облака требуется лишь создать виртуалку с убунтой и выдать тебе пароль от рута, то заменить такое облако на любое другое - дело получаса. А если ты весь процесс завязал на какие-то проприетарные конфигурации и сервисы, поднять которые у другого провайдера нетривиально - тут да, будет ой.

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

vbr ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

По хорошему, у каждого проекта должны быть вот такие … стойки, нафаршированные железом и ОС которые поддерживаются

На это сразу возникают вопросы (в порядке увеличения сложности):

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

  2. Кто будет заниматься выбором и закупкой железа?

  3. Где оно будет стоять и гудеть, жрать электричество, охлаждаться?

Поэтому IaaS нужен. Он хотя бы позволяет решить все вопросы деньгами, причём приемлемыми.

А чтобы это было, нужна хоть какая-то монетизация что к сожалению в отношении СПО воспринимается в штыки

Монетизация — это про бизнес. Превращение СПО-проектов в бизнес а) требует совсем других навыков; б) радикально меняет постановку задачи для СПО-проектов, ведь теперь им нужно зарабатывать. В результате помимо выгоревших мейнтейнеров (их станет даже больше) мы получим ещё и прогоревших. Так что дело не только в жадности пользователей.

поэтому FOSS почти весь, завязан по гланды на SaaS, к котрому есть только ямловый интерфейс

По-моему, всё не так. По-моему, CI в массы пошёл благодаря тому, что SaaS-сервисы (Travis и Appveyor) радикально снизили порог входа, а вовсе не из-за того, что людям не где было крутить Jenkins. Кинул файлик в репу и оно работает.

и при отвале SaaS отваливается половина FOSS, как минимум релизы и тестирование, тупо неначем делать.

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

annulen ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.