Симптом: сборка Mac Runner завершается, но журналы, сводка или артефакт не отображаются в GitHub Actions.
Быстрое решение: проверьте, разрешены ли конечные точки blob storage по отдельности. Если политика уже охватывает соответствующие домены по шаблону, сначала подтвердите область действия правила: отдельная запись для новых хостов обычно не нужна. При списке отдельных имён сверьте его с текущими данными GitHub Meta API, обновите правила и проверьте реальный рабочий процесс.
Эта инструкция для администраторов межсетевого экрана, прокси и DNS-фильтрации, отвечающих за выход в сеть GitHub Actions. Она также пригодится инженерам платформы, управляющим самостоятельно размещёнными Mac Runner, и владельцам процесса выпуска, которым нужна воспроизводимая приёмка сетевых изменений.
Последняя проверка — 27 октября 2026 года. Сверены объявление GitHub от 22 октября 2026 года, документация Meta API и требования к сети для самостоятельно размещённых Runner: объявление о новых конечных точках blob storage, документация Meta API и справочник по сетевым требованиям Runner.
Метрика покрытия: определите, какие конечные точки уже разрешены
Изменение касается хостов GitHub Actions blob storage на GitHub.com. Это не изменение меток Runner, конфигурации workflow-файла или версии инструментария сборки. GitHub сообщил о новых хостах 22 октября 2026 года и указал две группы конечных точек; при этом организации с правилами, покрывающими соответствующие домены по шаблону, обычно не должны добавлять записи для новых хостов. Если в политике перечислены отдельные имена, их нужно сверить и при необходимости дополнить согласно объявлению GitHub.
Не переносите строку из старой заявки, внутренней вики или примера документации в роль постоянного источника. Объявление фиксирует конкретное изменение, но текущий список нужно получать из официального API, а затем проверять применительно к вашей политике. Важна не только запись в интерфейсе межсетевого экрана: доменное правило может обрабатываться прокси, DNS-фильтром, системой управления политиками или отдельной сетевой границей Runner.
Сначала выясните, чем именно управляет ваша организация:
- отдельными полными именами хостов;
- доменными шаблонами, например правилом для поддомена;
- IP-адресами или диапазонами адресов;
- комбинацией DNS-фильтрации, прокси и сетевых ACL.
Для инвентаризации зафиксируйте имя политики, её владельца, область действия и способ сопоставления доменов. Затем установите, какие Runner или подсети применяют эту политику. Если Mac CI разделён на рабочие группы с разными прокси, единый ответ «у нас есть wildcard» недостаточен: нужно убедиться, что подходящее правило действует на каждом целевом маршруте.
Метрика точности: решите, требуется ли менять правило
Одинаковое обновление списка может быть необходимо в одной сети и избыточно в другой. Решение зависит от точности правила и его реальной области действия, а не от факта появления новых имён в объявлении.
| Тип сетевой политики | Что проверить | Действие по результату |
|---|---|---|
| Разрешены только перечисленные хосты | Есть ли все актуальные конечные точки из официальных данных | Если новых имён нет, согласуйте добавление по процедуре изменений |
| Разрешён подходящий домен по шаблону | Охватывает ли шаблон указанные GitHub домены и применяется ли к Runner | Если охват подтверждён, отдельные записи обычно не требуются |
| Разрешены IP-адреса или диапазоны | Поддерживает ли политика динамические адреса и соответствует ли текущим данным официального источника | Не заменяйте проверку домена широким разрешением без оценки модели риска |
| Правила распределены между прокси, DNS и ACL | Совпадают ли настройки всех точек выхода для нужной сети | Проверяйте каждую точку, иначе частичное разрешение может выглядеть как случайный сбой |
Когда новые записи не нужны, а когда список следует дополнить?
Используйте следующие условия как краткое решение для изменения политики:
- Если подтверждено, что активное правило разрешает нужные поддомены blob storage, то не добавляйте отдельные записи только из-за объявления; сначала проверьте реальный маршрут и работу правила.
- Если разрешены исключительно отдельные имена хостов, то сравните их с текущим официальным списком и запросите добавление недостающих имён.
- Если правило задано IP-адресами, то не копируйте в него доменные имена и не раскрывайте доступ ко всему диапазону «на всякий случай»; согласуйте допустимый способ фильтрации с владельцем сетевой политики.
- Если нет уверенности, где применяется правило, то сначала проследите путь от Runner через DNS, прокси и межсетевой экран; иначе изменение может быть внесено не в ту точку.
- Если после корректировки сетевое соединение устанавливается, но артефакты всё ещё не доступны, то не считайте сетевой отказ доказанным: отдельно проверьте права workflow, конфигурацию передачи данных и сообщения об ошибках.
Метрика актуальности: сверяйте список через Meta API
GitHub описывает Meta API как источник сведений о метаданных сервиса; для сетевой инвентаризации используйте справочник Meta API и текущий ответ GitHub Meta API. Документация и API выполняют разные задачи: первая объясняет структуру и назначение интерфейса, второй даёт текущие опубликованные данные. Пример ответа в документации не заменяет фактический запрос при внесении изменения.
Для первичной проверки получите ответ из сети администратора или из согласованной среды автоматизации:
curl -fsS -H 'Accept: application/vnd.github+json' \
https://api.github.com/metaСохраните полный ответ вместе с датой получения, затем найдите в документации соответствующий раздел или поле для GitHub Actions. Не предполагайте, что найденная в старом скрипте структура остаётся неизменной: перед автоматической обработкой проверьте актуальную схему и обработайте случай отсутствующего или неожиданного поля. Если ваша сеть не может обратиться к API напрямую, используйте утверждённый процесс получения данных и сохраняйте источник, время получения и ответственных за перенос в политику.
Рабочая сверка должна оставлять след, который можно проверить при аудите. В записи изменения укажите:
- ссылку на официальный источник и дату извлечения данных;
- фрагмент актуального ответа, использованный для сопоставления;
- прежние и предложенные правила с пояснением, что изменилось;
- подсети, прокси или группы Runner, на которые распространяется изменение;
- результат согласования и последующей проверки workflow.
Для проверки времени между пересмотрами установите собственное правило на основе изменений источника и риска: повторная сверка нужна при обновлении объявления, изменении документации сетевых требований, смене используемого способа фильтрации или появлении подтверждённых проблем в целевой сети. Для чувствительных сред добавьте плановую проверку в регламент, но назначьте конкретный интервал только после оценки внутренних требований и нагрузки на сопровождение.
Метрика функционального охвата: отделите blob storage от других зависимостей CI
Конечные точки хранения участвуют в рабочих процессах, где GitHub Actions передаёт и получает данные. Но не всякая проблема с workflow относится к ним. Документация по сетевым требованиям самостоятельно размещённых Runner перечисляет сетевую коммуникацию, необходимую для работы Runner; её следует читать целиком, а не сводить всю доступность CI к одному домену.
Проверьте, какие из перечисленных ниже цепочек действительно используются вашими workflow. Конкретный перечень зависит от конфигурации сборки, действий и внутренних политик:
| Проверяемый результат | Что проверить в workflow и журналах | Что нельзя автоматически заключать |
|---|---|---|
| Журнал выполнения | Доступен ли журнал из интерфейса GitHub Actions; есть ли сетевые ошибки у Runner | Что недоступный журнал всегда означает блокировку blob storage |
| Сводка выполнения | Создаёт ли workflow сводку и передаётся ли она в рамках завершения задания | Что отсутствие сводки вызвано тем же компонентом, что и ошибка доступа к исходному коду |
| Артефакт | Используется ли загрузка или скачивание артефактов и что сообщает действие | Что успешная сборка подтверждает успешную передачу артефакта |
| Кэш зависимостей | Использует ли workflow кэш и завершилась ли операция чтения или записи | Что сбой кэша обязательно затрагивает артефакты или журналы |
Это различие важно при диагностике Mac CI. Если Runner не может получить код, проверьте доступ к репозиторию и соответствующие сетевые требования; если не проходит авторизация, проверьте секреты, токены и разрешения workflow; если нет журнального события о сетевом отказе, не приписывайте проблему межсетевому экрану только потому, что она проявилась после объявления. Отдельно учитывайте DNS-ошибки, отказ прокси, блокировку на межсетевом экране и отказ приложения: это разные причины и разные владельцы исправления.
Метрика приёмки: подтвердите правило на реальном Mac Runner
Проверка конфигурации показывает намерение, но не доказывает, что конкретный Runner использует нужную политику. Для приёмки нужен workflow, выполняемый в той же сетевой зоне и с тем же маршрутом, что и рабочие сборки. Не подменяйте проверку просмотром настроек межсетевого экрана или тестом из ноутбука администратора.
Выполните процедуру по шагам:
- Выберите репрезентативный workflow. Он должен использовать тот же пул Mac Runner, прокси и DNS-политику, что и целевой процесс. Если разные группы Runner выходят в сеть по-разному, проверяйте каждую затронутую группу отдельно.
- Зафиксируйте исходное состояние. Сохраните идентификатор изменения сетевого правила, время запуска, идентификатор Runner и относящиеся к проверке записи DNS, прокси и межсетевого экрана. Не помещайте секреты, токены и чувствительные данные сборки в общий отчёт.
- Проверьте журналы и сводку. Убедитесь, что выполнение можно открыть и что ожидаемая сводка появилась. Если отсутствует один из результатов, зафиксируйте сообщение workflow и сетевые события, а не только скриншот пустой страницы.
- Проверьте фактически используемые передачу артефактов и кэш. Запустите только те операции, которые входят в реальный процесс команды, затем подтвердите результат на стороне workflow. Успешный шаг компиляции сам по себе не проверяет передачу артефакта.
- Сопоставьте событие с политикой. Сверьте разрешённый домен и точку выхода с журналами DNS, прокси и межсетевого экрана. Если сбой повторяется, определите, получен ли отказ до соединения, при установлении соединения или уже на уровне workflow.
- Оформите результат и откат. Запишите, какие функции проверены, для какого пула Runner и каким правилом; оставьте владельцу сети конкретный способ возврата к предыдущей политике, если изменение вызвало побочный эффект.
Если логов недостаточно, сопоставьте временные отметки Runner с журналами сетевых систем. Ошибка DNS указывает на иной участок проверки, чем явный отказ прокси; блокировка ACL отличается от отказа разрешений workflow. Такая классификация снижает риск расширить сетевой доступ, когда исправлять требуется конфигурацию задания или права.
Метрика управляемости: закрепите процедуру обновления
Обновление конечной точки не должно зависеть от того, кто случайно увидел объявление. Назначьте владельца списка, владельца сетевого правила и ответственного за приёмку CI. В небольших командах эти роли могут совмещаться, но сами обязанности должны быть понятны: кто обнаруживает изменение, кто утверждает правило и кто подтверждает работу Runner.
Внутренний регламент должен объяснять, где искать актуальные данные, как отличать точечную запись от доменного шаблона и какие workflow используются для проверки. Добавьте ссылку на официальный источник, укажите, какая сеть или группа Runner охвачена, и храните результат проверки рядом с заявкой на изменение. Не делайте снимок API единственным бессрочным справочником: он подтверждает состояние на момент получения, а не гарантирует постоянство списка.
Планируйте повторную проверку при изменении официальной документации, появлении нового объявления, смене сетевого маршрута или отказе проверяемой функции. Внеплановая проверка также оправдана при переносе Runner в другую подсеть, изменении прокси или разделении Mac CI на самостоятельные сетевые сегменты. Для адресных правил отдельно документируйте, почему выбран именно такой способ ограничения: решение должно быть совместимо с реальной моделью фильтрации и требованиями безопасности, а не только удобно для внедрения.
Если рабочие станции и CI используют разные сетевые контуры, документируйте это разделение. Отдельный контур для Mac сборок может требовать собственного процесса управления DNS, исходящими соединениями и журналами. Однако само наличие отдельного контура не является основанием разрешать больше: правила следует оценивать по задачам workflow, применённой политике и результатам приёмки.
Для команд, оценивающих, где размещать Mac CI, полезно отдельно сопоставить операционные обязанности и доступные режимы управления в руководстве MACGPU по Mac. Это не заменяет проверку конкретных сетевых условий: перед выбором среды запросите и подтвердите применимые сведения о сетевом доступе, журналировании и способе приёмки.
После завершения проверки обновите внутреннюю запись так, чтобы следующий дежурный мог ответить на три вопроса без догадок: какой официальный источник проверяли, какое правило действует на Runner и какой workflow подтвердил требуемую передачу данных. Если остаётся неизвестным хотя бы один из этих пунктов, изменение ещё нельзя считать полностью проверенным.
Если у команды есть собственные Mac, вы сохраняете физический контроль, но несёте расходы на закупку и замену устройств, а также нагрузку на настройку и сопровождение сетевой политики. Общая облачная среда может сократить часть инфраструктурных обязанностей, но её сетевые условия и границы управления нужно проверять до переноса CI. Для временного пилота, дополнительного пула или отдельного Mac-сценария аренда удалённого Mac у MACGPU может быть практичнее покупки постоянного оборудования — при условии, что подтверждённые условия доступа подходят вашей политике. Сверьте доступные варианты на странице аренды Mac и до использования прогоните тот же набор сетевых проверок: журналы, сводки и реальные артефакты.