Кратко

  • GitHub Actions может запустить workflow_run, когда другой workflow запрошен или завершён; GitHub указывает, что последующий workflow может получить секреты и токены записи, недоступные предыдущему.
  • Эта связь не является выводом о доверии к артефакту: условие результата, фильтр ветки, checkout, выбор и обработка артефакта, а также фактические привилегии остаются отдельными решениями.
  • Проверяемое утверждение связывает предшествующий запуск и ревизию, настройку и вычисленные условия последующего триггера, точные артефакт и checkout, контекст привилегий, последующее решение и ограниченное по времени наблюдение цели.

Фраза «публикация выполнилась после проверки» может описывать архитектуру, но не полную цепочку хранения. GitHub Actions позволяет одному workflow слушать событие workflow_run другого workflow в момент запроса или завершения последнего. GitHub также пишет, что запущенный workflow может получить доступ к секретам и токенам записи, хотя предшествующий workflow этого не мог. Такое разделение может быть разумным: входная работа с меньшими привилегиями создаёт кандидат, а следующая, более строго ограниченная стадия решает, как с ним поступить. Но оно одновременно образует границу привилегий. Имя предшествующего запуска не показывает, что пересекло эту границу.

Прежде всего надо различать завершение и принятие. GitHub документирует, что запуск workflow_run выполняется независимо от вывода предыдущего workflow, если в последующем workflow нет явного условия, например github.event.workflow_run.conclusion == 'success'. Значит, завершённый предшествующий запуск не доказывает ни успех проверок, ни того, что последующая задача вычислила ожидаемое условие результата. Имя workflow в событии — это не ревизия файла, который его слушает, не содержание полученного события и не выражение, разрешившее привилегированный шаг.

У фильтров веток та же граница. GitHub указывает, что фильтры веток workflow_run применяются к ветке запускающего workflow, а шаблоны включения и исключения имеют порядок. Объявленное значение branches может фиксировать намерение политики. Оно не доказывает, что артефакт получен из ожидаемого коммита, что последующий checkout разрешился в ту же ревизию или что формула «ветка релиза прошла» действительно называет проверенный ref. Если это утверждение должно подлежать разбору, идентификатор предшествующего запуска, действие события, head-ветка и SHA, идентичность workflow и контекст повторного запуска нужно сохранить вместе.

Затем появляется артефакт. В документации GitHub по событиям показано, что последующий workflow может получить артефакты, связанные с запуском, вызвавшим его. Это путь доступа, а не сертификат качества. Артефакт может быть правильно привязан к запуску и всё же быть неверным логическим вводом для последующего действия. Workflow может выбрать другое имя, загрузить набор вместо одного объекта, распаковать его в иной среде, использовать другой checkout или передать артефакт команде, которую предшествующая проверка не оценивала. Нужная запись — не просто «артефакт доступен».

Она связывает исходный запуск, имя или идентификатор, размер и дайджест при наличии, время получения, ref и разрешённый SHA последующего checkout, программу-потребитель и условия изоляции либо неисполнения при обработке.

Справочник GitHub по безопасному использованию объясняет, почему такая точность важна. Он предупреждает, что workflow_run может быть опасен, когда привилегированный workflow делает checkout недоверенного содержимого pull request; секреты, права записи и общие кэши способны усилить последствия того, что принимает последующий workflow. Это предупреждение не обвиняет конкретный репозиторий или артефакт. Оно описывает устройство: утверждение «предыдущий workflow прошёл» не показывает, что принял привилегированный следующий workflow и что ему было позволено с этим сделать.

Триггер также не является квитанцией об эффекте на цели. Даже корректно выбранный артефакт может быть использован только для инспекции. Последующая команда может быть отклонена другой границей разрешений, остановиться до вызова цели, воздействовать на другой ресурс или завершиться, хотя более позднее наблюдение цели покажет другое рабочее состояние. И наоборот, отрицательный вывод предшествующего workflow может присутствовать в событии, а условие следующего workflow заблокирует все привилегированные действия. Событие, условие, обработка артефакта, решение команды и наблюдаемое состояние — разные точки.

Практический ответ — ограниченная последующая квитанция. Следует сохранить имя и идентификатор предшествующего workflow, действие события, head-ветку и SHA, вывод, попытку или повторный запуск и устойчивую ссылку на его определение. Следует сохранить ревизию определения последующего workflow, селектор workflow_run, фильтры веток и результат условия, разрешившего или заблокировавшего значимую задачу. Нужны спецификации checkout и разрешённые SHA. Для каждого использованного артефакта нужны исходная связь, имя или идентификатор, доступный дайджест, контекст получения и путь обработки. Следует сохранить фактический контекст прав GITHUB_TOKEN, доступности секретов и относящихся границ кэша или среды, не раскрывая чувствительные значения. Наконец, результат последующей операции надо связать с отдельным по времени наблюдением цели. Секреты можно защитить; связи, которые не были записаны, невозможно восстановить задним числом.

Эта дисциплина не объявляет весь конвейер «доверенным». Она говорит, что именно связало событие, что решил последующий workflow, что он потребил, какими привилегиями обладал и что наблюдалось. workflow_run может быть полезной контрольной границей. Его нельзя превращать в неявный сертификат артефакта, привилегированного решения и операционного эффекта, которые он не зафиксировал.

Источники

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow