Я просматривал документы, а также пробовал различные экспериментальные изменения с помощью файла .travis.yml, чтобы переключать мои сборки на основе того, были ли изменения, связанные с кодом, в проекте или это просто изменения, связанные с документацией.
Все те пользователи, которые не внесли изменения, должны несправедливо дождаться завершения предыдущих сборок, особенно если эти предыдущие сборки были вызваны изменениями, не связанными с кодом.
Но все равно требуется 30-За 40 секунд до выхода PR из билда. Последующие коммиты и PR ожидают в очереди. Мы думаем, что это можно еще улучшить, если мы не запустим виртуальную машину TravisCI и сможем выполнить те же проверки на уровне ловушки github. Мы хотим оптимизировать его дальше, чем за несколько секунд, чтобы понять, нужен ли нашему пиару сборка CI / CD или нет.
Справочная информация: В сообществе TravisCI возникла проблема, но пока нетбыл ощутимый ответ: https://travis -ci.community / t / условная сборка без запуска-travisci-vms / 5305/2
Мы предложили решение для проверкидля этого в директиве before_install
и затем пропускает сборку с помощью выхода 0.
https://github.com/picknmix/picknmix/blob/master/.travis.yml
Я ищу следующее:
- По сути, git знает, какие файлы были изменены в коммите или ветке (что также является коммитом). Если эта информация доступна в переменной envis TravisCI, это одна часть информации
В моем случае я ищу расширения файлов, поэтому аналогично эту информацию можно сделать доступной в переменной окружения или директивев зависимости от того, что работает
язык выражений должен позволять выражать такие вещи, как:
${TRAVISCI_COMMIT_FILE_EXTENSIONS} contain any of (xx xxx x xyz)
или
${TRAVISCI_COMMIT_FILE_EXTENSIONS} does not contain any of (xx xxx x xyz)
Иесли приведенное выше возвращает true или false, мы можем затем добавить это условие в переменную окружения или напрямую вызвать его с помощью директивы if:
if: <condition>
или
if: <do not run build if no code changes have been made directive>
или
if: <run build only if code changes have been made directive>
Это мое основное понимание, конечно, это не совсем то, что я описал выше, но затем, глядя на доступные документы и функциональность, мы можем преодолеть разрыв.
Эта функциональность сама по себе, если TravisCIможет обеспечить с помощью одной директивы может сэкономить каждому много времени на сборку и ждать начала сборки, потому что сборка застряла в очереди, занятой другими сборками, которые являются exeобрезка коммитов или триггеров ветвления изменений, не связанных с кодом.