Libseccomp: ОШИБКА: попробуйте заменить Travis CI действиями GitHub

Вот руководство по переходу с TravisCI на Github Actions. Я надеюсь поэкспериментировать с этим в ближайшие несколько дней
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions / migrating-from-travis-ci-to-github-actions

Мне очень нравится внешний вид Github Actions. Я только что разослал набор патчей для переключения libcgroup с Travis CI на Github Actions.

https://github.com/drakenclimber/libcgroup/tree/issues/github_actions
https://sourceforge.net/p/libcg/mailman/message/37165461/

На этой неделе я попытаюсь собрать набор патчей для перехода на libseccomp.

Звучит неплохо, @drakenclimber , спасибо!

Вот мой текущий статус. У меня есть Github Actions, работающие над amd64 с некоторыми небольшими отклонениями от нашего текущего решения Travis CI, но у меня есть опасения по поводу других архитектур.

Плюсы:

• Легко использовать. Мне удалось быстро настроить рабочий процесс непрерывной интеграции в Github Actions.
• Также легко инкапсулировать операции в действие . Затем эти действия можно повторно использовать в рабочем процессе. (Как ни странно, действие не может вызвать другое действие .)
• Приемлемая скорость (как минимум для amd64). Полный набор тестов завершен за 22 минуты
• Хороший графический интерфейс и неудачные шаги четко обозначены
• Мне очень нравятся параметры распараллеливания Github Actions, и он предоставляет возможность сопоставлять результаты после завершения других заданий. Я использую эту функцию в libcgroup, чтобы окончательно уточнить

Минусы:

• Нет встроенной поддержки для других архитектур
  
  
  
  • Сотрудник github предоставил этот обходной путь для запуска контейнера Docker arm64. Я попробовал это и, немного поигравшись, смог добиться, чтобы базовый набор тестов в основном работал. (Тест 52 - базовая нагрузка - завершился неудачно по какой-то странной причине.) Но эту настройку трудно воспроизвести локально, и отладка представляет собой серьезную проблему. Мне не удалось заставить работать тесты Python. О, и это действительно очень медленно - на выполнение урезанного набора тестов на arm64 потребовался час. ppc64el потребовалось 6 часов, прежде чем я его убил :(
  
  
  • Пользователь github создал это действие, которое также использует контейнеры Docker для запуска неродных архитектур. Синтаксис несколько неуклюжий и потребует от нас дублирования кода. Хотя его поддерживаемая архитектура и список платформ довольно хороши.
  
  
  • Github Actions поддерживает использование автономных бегунов , поэтому один (уродливый) вариант - найти выделенный ящик для arm64, ppc64le и т. Д. И использовать его для запуска тестов. Преимущество этого заключается в том, что отладка будет намного проще, чем с контейнером Docker.
  
  

Другой:

• Coshopss.io создал действие на Github . Наше существующее решение TravisCI, cpp-coshops , действительно работает с Github Actions, но не справлялось с параллельными сборками. У меня есть действие Комбинезоны, работающее параллельно в libcgroup
• Чтобы использовать действие Coshops , мне пришлось эта строка покрыта или нет, в то время как решение Github Actions явно называет ее раскрытой . Я считаю, что в этом случае Github Actions верны, и в нашем текущем решении немного неверно указан номер покрытия.
• Примечание для себя - у меня не работает флаг --exclude src/arch-syscall-check.c lcov. Не знаю почему

Вот мой текущий статус. У меня есть Github Actions, работающие над amd64 с некоторыми небольшими отклонениями от нашего текущего решения Travis CI, но у меня есть опасения по поводу других архитектур.

Плюсы:

• Легко использовать. Мне удалось быстро настроить рабочий процесс непрерывной интеграции в Github Actions.
• Также легко инкапсулировать операции в действие . Затем эти действия можно повторно использовать в рабочем процессе. (Как ни странно, действие не может вызвать другое действие .)
• Приемлемая скорость (как минимум для amd64). Полный набор тестов завершен за 22 минуты
• Хороший графический интерфейс и неудачные шаги четко обозначены
• Мне очень нравятся параметры распараллеливания Github Actions, и он предоставляет возможность сопоставлять результаты после завершения других заданий. Я использую эту функцию в libcgroup, чтобы окончательно уточнить

Минусы:

• Нет встроенной поддержки для других архитектур

  • Сотрудник github предоставил этот обходной путь для запуска контейнера Docker arm64. Я попробовал это и, немного поигравшись, смог добиться, чтобы базовый набор тестов в основном работал. (Тест 52 - базовая нагрузка - завершился неудачно по какой-то странной причине.) Но эту настройку трудно воспроизвести локально, и отладка представляет собой серьезную проблему. Мне не удалось заставить работать тесты Python. О, и это действительно очень медленно - на выполнение урезанного набора тестов на arm64 потребовался час. ppc64el потребовалось 6 часов, прежде чем я его убил :(
  • Пользователь github создал это действие, которое также использует контейнеры Docker для запуска неродных архитектур. Синтаксис несколько неуклюжий и потребует от нас дублирования кода. Хотя его поддерживаемая архитектура и список платформ довольно хороши.
  • Github Actions поддерживает использование автономных бегунов , поэтому один (уродливый) вариант - найти выделенный ящик для arm64, ppc64le и т. Д. И использовать его для запуска тестов. Преимущество этого заключается в том, что отладка будет намного проще, чем с контейнером Docker.

Другой:

• Coshopss.io создал действие на Github . Наше существующее решение TravisCI, cpp-coshops , действительно работает с Github Actions, но не справлялось с параллельными сборками. У меня есть действие Комбинезоны, работающее параллельно в libcgroup
• Чтобы использовать действие Coshops , мне пришлось эта строка покрыта или нет, в то время как решение Github Actions явно называет ее раскрытой . Я считаю, что в этом случае Github Actions верны, и в нашем текущем решении немного неверно указан номер покрытия.
• Примечание для себя - у меня не работает флаг --exclude src/arch-syscall-check.c lcov. Не знаю почему

А как насчет использования Vagrant на macOS?

А как насчет использования Vagrant на macOS?

Эта проблема связана с переносом нашего тестирования CI из Travis CI в GitHub Actions, а не с общей разработкой и тестированием libseccomp. Я не уверен, что MacOS - это вариант для GitHub Actions, и даже если бы он был, он, вероятно, был бы плохим выбором для нас из-за отсутствия поддержки ядра (наши «живые» тесты ограничены, но важны).

Вот мой текущий статус. У меня есть Github Actions, работающие над amd64 с некоторыми небольшими отклонениями от нашего текущего решения Travis CI, но у меня есть опасения по поводу других архитектур.

Спасибо, что заглянули в этот

Относительно комментариев lcov / Комбинезон; Раньше я замечал похожие вещи, но не особо беспокоился о различиях, поскольку они были незначительными. Интересно, можно ли использовать lcov в Travis и загрузить файл lcov как часть сборки Travis без утечки кредитов в конфигурации Travis? Если нет ничего другого, что обеспечит согласованность между локальным использованием и использованием Travis, и это может немного упростить задачу, если / когда мы перейдем с Travis CI.

А как насчет использования Vagrant на macOS?

Эта проблема связана с переносом нашего тестирования CI из Travis CI в GitHub Actions, а не с общей разработкой и тестированием libseccomp. Я не уверен, что MacOS - это вариант для GitHub Actions, и даже если бы он был, он, вероятно, был бы плохим выбором для нас из-за отсутствия поддержки ядра (наши «живые» тесты ограничены, но важны).

Я хорошо знаком с действиями GitHub. Они поддерживают macOS (см. Https://github.com/actions/virtual-environments#available-environments). В частности, macOS - единственная среда, которая поставляется с Vagrant и VirtualBox (см. Https://github.com/actions/virtual-environments/issues/433).

По моему опыту, для его настройки требуется немного больше работы, но запуск внутри виртуальной машины обеспечивает более согласованную среду для конвейеров CI / CD. Не говоря уже о том, что он более переносимый, поскольку любой может запускать образы Vagrant / VirtualBox локально. Это также упрощает переход на новое решение CI / CD, поскольку конфигурация обычно записывается в сценарии, независимо от деклараций YAML для конкретных поставщиков.

Это всего лишь мои два цента :)

Спасибо @ oxr463 , приятно узнать о GH Actions. На этом этапе я бы предпочел не иметь дополнительных накладных расходов на управление виртуальной средой, но это нужно учитывать, если Travis CI когда-нибудь станет для нас проблемой.

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

Спасибо, что заглянули в этот

Да, я думаю, это лучший и самый безопасный ответ.

Относительно комментариев lcov / Комбинезон; Раньше я замечал похожие вещи, но не особо беспокоился о различиях, поскольку они были незначительными. Интересно, можно ли использовать lcov в Travis и загрузить файл lcov как часть сборки Travis без утечки кредитов в конфигурации Travis? Если нет ничего другого, что обеспечит согласованность между локальным использованием и использованием Travis, и это может немного упростить задачу, если / когда мы перейдем с Travis CI.

Да, это должно быть возможно. Я создал выпуск № 309 и присвоил его себе. Постараюсь забрать это через неделю или две.

Спасибо

По моему опыту, для его настройки требуется немного больше работы, но запуск внутри виртуальной машины обеспечивает более согласованную среду для конвейеров CI / CD. Не говоря уже о том, что он более переносимый, поскольку любой может запускать образы Vagrant / VirtualBox локально. Это также упрощает переход на новое решение CI / CD, поскольку конфигурация обычно записывается в сценарии, независимо от деклараций YAML для конкретных поставщиков.

Спасибо, @ oxr463. Я также надеюсь, что нам не придется идти этим путем, но приятно знать, что есть и другие варианты.

@drakenclimber Я собираюсь отбросить это от этапа выпуска и снизить приоритет до низкого, поскольку мы применяем подход «подождите, пока он не сломается». Если вы не согласны, не стесняйтесь кричать или просто корректировать метки соответственно.

@drakenclimber Я собираюсь отбросить это от этапа выпуска и снизить приоритет до низкого, поскольку мы применяем подход «подождите, пока он не сломается». Если вы не согласны, не стесняйтесь кричать или просто корректировать метки соответственно.

Звучит неплохо. Спасибо!

@drakenclimber мне пришла в голову одна вещь - нам следует подумать о попытке перехода с travis-ci.org на travis-ci.com, поскольку ".org" якобы исчезнет "в течение нескольких недель".

Ой! Не знал этого. Спасибо!

Тогда попробую забрать это на следующей неделе.