{"meta":{"title":"Синтаксис рабочего процесса для GitHub Actions","intro":"Рабочий процесс — это настраиваемый автоматизированный процесс, состоящий из одного или нескольких заданий. Чтобы определить конфигурацию рабочего процесса, необходимо создать YAML-файл.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/reference","title":"Справочные материалы"},{"href":"/ru/actions/reference/workflows-and-actions","title":"Рабочие процессы и действия"},{"href":"/ru/actions/reference/workflows-and-actions/workflow-syntax","title":"Синтаксис рабочего процесса"}],"documentType":"article"},"body":"# Синтаксис рабочего процесса для GitHub Actions\n\nРабочий процесс — это настраиваемый автоматизированный процесс, состоящий из одного или нескольких заданий. Чтобы определить конфигурацию рабочего процесса, необходимо создать YAML-файл.\n\n## Сведения о синтаксисе YAML для рабочих процессов\n\nФайлы рабочего процесса используют синтаксис YAML и должны иметь расширение файла `.yml` или `.yaml`. Если вы не знакомы с YAML и хотите узнать больше, ознакомьтесь с разделом [\"Сведения о YAML\" в минутах](https://learnxinyminutes.com/docs/yaml/) Y.\n\nФайлы рабочего процесса необходимо хранить в каталоге `.github/workflows` репозитория.\n\n> \\[!TIP]\n> В отличие от традиционных GitHub Actions рабочих процессов, требующих выполнения каждого решения в качестве действий задания YAML, используйте интерфейсное средство YAML для триггеров и конфигурации, GitHub Agentic Workflows но позвольте описать, что нужно в Markdown естественного языка, поэтому вам не нужно заранее предвидеть и кодировать каждый сценарий. Дополнительные сведения см. в разделе [Создание агентских рабочих процессов GitHub](/ru/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows).\n\n## `name`\n\nИмя рабочего процесса. GitHub отображает имена рабочих процессов на вкладке \"Действия\" репозитория. Если не указано `name`, GitHub отображает путь к файлу рабочего процесса относительно корневого каталога репозитория.\n\n## `run-name`\n\nИмя рабочего процесса, созданное из рабочего процесса.\nGitHub отображает название запуска рабочего процесса в списке запущенных рабочих процессов на вкладке «Действия» вашего репозитория. Если `run-name` пропущено или это только пробел, то название запуска устанавливается на информацию, специфичную для события, для запуска рабочего процесса. Например, для рабочего процесса, активированного событием `push` или событием, оно устанавливается как сообщение фиксации или `pull_request` название запроса на вытягивание.\n\nЭто значение может включать выражения и может ссылаться на [`github`](/ru/actions/reference/workflows-and-actions/contexts#github-context) них и [`inputs`](/ru/actions/reference/workflows-and-actions/contexts#inputs-context) контексты.\n\n### Пример `run-name`\n\n```yaml\nrun-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}\n```\n\n## `on`\n\nЧтобы автоматически активировать рабочий процесс, используйте `on` для указания событий, которые могут привести к запуску рабочего процесса. Список доступных событий см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\nМожно определить одно или несколько событий, которые могут активировать рабочий процесс или задать расписание времени. Можно также настроить рабочий процесс так, чтобы он выполнялся только для определенных файлов, тегов или изменений ветвей. Описание этих параметров приводится в следующих разделах.\n\n### Использование одного события\n\nНапример, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории рабочего процесса:\n\n```yaml\non: push\n```\n\n### Использование нескольких событий\n\nМожно указать одно или несколько событий. Например, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории, или когда кто-то создает вилку репозитория:\n\n```yaml\non: [push, fork]\n```\n\nЕсли указано несколько событий, для активации рабочего процесса необходимо, чтобы произошло только одно из них. Если одновременно происходят несколько событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов.\n\n### Использование типов действий\n\nНекоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте `on..types` для определения типа действия для события, которое активирует запуск рабочего процесса.\n\nНапример, событие `issue_comment` имеет типы действий `created`, `edited` и `deleted`. Если рабочий процесс активируется в событии `label`, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия `created` для события `label`, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки.\n\n```yaml\non:\n label:\n types:\n - created\n```\n\nЕсли указать несколько типов действий, для активации рабочего процесса потребуется выполнить только один из этих типов действий. Если одновременно происходят несколько типов действий для событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов. Например, следующий рабочий процесс активируется при открытии проблемы или добавлении для нее метки. Если открывается проблема с двумя метками, начинаются три запуска рабочего процесса: один для события открытия проблемы и два для двух событий проблем с метками.\n\n```yaml\non:\n issues:\n types:\n - opened\n - labeled\n```\n\nДополнительные сведения о каждом событии и их типах действий см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Использование фильтров\n\nНекоторые события имеют фильтры, позволяющие лучше контролировать выполнение рабочего процесса.\n\nНапример, событие `push` имеет фильтр `branches`, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру `branches`, а не при любой отправке.\n\n```yaml\non:\n push:\n branches:\n - main\n - 'releases/**'\n```\n\n### Использование типов действий и фильтров с несколькими событиями\n\nЕсли вы указываете типы действий или фильтры для события и триггеры рабочего процесса для нескольких событий, необходимо настроить каждое событие отдельно. Необходимо добавить двоеточие (`:`) ко всем событиям, включая события без конфигурации.\n\nНапример, рабочий процесс со следующим значением `on` будет выполняться в следующих случаях:\n\n* создание метки;\n* отправка в ветвь `main` в репозитории;\n* отправка в ветвь с поддержкой GitHub Pages.\n\n```yaml\non:\n label:\n types:\n - created\n push:\n branches:\n - main\n page_build:\n```\n\n## `on..types`\n\nИспользуйте `on..types` для определения типа действия для события, которое активирует выполнение рабочего процесса. Большинство событий GitHub активируются несколькими типами действий. Например, `label` активируется, если метка имеет значение `created`, `edited` или `deleted`. Ключевое слово `types` позволяет сузить действие, которое приводит к выполнению рабочего процесса. Если только один тип действия активирует событие веб-перехватчика, ключевое слово `types` не требуется.\n\nМожно использовать массив событий `types`. Дополнительные сведения о каждом событии и их типах действий см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n```yaml\non:\n label:\n types: [created, edited]\n```\n\n## `on..`\n\nПри использовании событий `pull_request` и `pull_request_target` можно настроить выполнение рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей.\n\nИспользуйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно.\n\nЕсли вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `branches` и `branches-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n### Пример: включение ветвей\n\nШаблоны, определенные в `branches`, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие `pull_request` для запроса на вытягивание, нацеленного на:\n\n* ветви с именем `main` (`refs/heads/main`);\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой начинается с `releases/`, например `releases/10` (`refs/heads/releases/10`);\n\n```yaml\non:\n pull_request:\n # Sequence of patterns matched against refs/heads\n branches:\n - main\n - 'mona/octocat'\n - 'releases/**'\n```\n\nЕсли рабочий процесс пропускается из-за фильтрации ветвей, [фильтрации](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) путей или [сообщения](/ru/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии \"Ожидание\". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.\n\n### Пример исключения ветвей\n\nВ случае соответствия шаблона `branches-ignore` рабочий процесс не будет выполняться. Шаблоны, определенные в `branches-ignore`, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие `pull_request`, если при этом запрос на вытягивание не нацелен на:\n\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой соответствует `releases/**-alpha`, например `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`); \n\n```yaml\non:\n pull_request:\n # Sequence of patterns matched against refs/heads\n branches-ignore:\n - 'mona/octocat'\n - 'releases/**-alpha'\n```\n\n### Пример: включение и исключение ветвей\n\nНельзя использовать `branches` и `branches-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр `branches` с символом `!`, чтобы указать, какие ветви следует исключить.\n\nЕсли вы определяете ветвь с символом `!`, необходимо также определить по крайней мере одну ветвь без символа `!`. Если вы хотите только исключить ветви, используйте вместо этого `branches-ignore`.\n\nПорядок определения шаблонов имеет значение.\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает ссылку Git.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.\n\nУказанный ниже рабочий процесс будет выполняться на событиях `pull_request` для запросов на вытягивание, нацеленных на `releases/10` или `releases/beta/mona`, но не для запросов на вытягивание, нацеленных на `releases/10-alpha` или `releases/beta/3-alpha`, потому что отрицательный шаблон `!releases/**-alpha` соответствует положительному шаблону. \n\n```yaml\non:\n pull_request:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.push.`\n\nПри использовании события `push` можно настроить выполнение рабочего процесса в определенных ветвях или тегах.\n\nИспользуйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно.\n\nИспользуйте фильтр `tags`, если требуется включить шаблоны имен тегов или как включить, так и исключить их. Используйте фильтр `tags-ignore`, если требуется только исключить шаблоны имен тегов. Для одного и того же события в рабочем процессе нельзя использовать фильтры `tags` и `tags-ignore` одновременно.\n\nЕсли вы определяете только или `tags`/`tags-ignore`только`branches`/`branches-ignore`, рабочий процесс не будет выполняться для событий, влияющих на неопределенную ссылку на Git. Если определить ни одно `tags`/`tags-ignore` или`branches`/`branches-ignore`, рабочий процесс будет выполняться для событий, влияющих на ветви или теги. Если вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `branches`, `branches-ignore`, `tags`и `tags-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей или тегов. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n### Пример. Включение ветвей и тегов\n\nШаблоны, определенные в `branches` и `tags`, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда событие `push` происходит в:\n\n* ветви с именем `main` (`refs/heads/main`);\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой начинается с `releases/`, например `releases/10` (`refs/heads/releases/10`);\n* теге с именем `v2` (`refs/tags/v2`);\n* теге, имя которого начинается с `v1.`, например `v1.9.1` (`refs/tags/v1.9.1`).\n\n```yaml\non:\n push:\n # Sequence of patterns matched against refs/heads\n branches:\n - main\n - 'mona/octocat'\n - 'releases/**'\n # Sequence of patterns matched against refs/tags\n tags:\n - v2\n - v1.*\n```\n\n### Пример. Исключение ветвей и тегов\n\nЕсли шаблон соответствует шаблону `branches-ignore` или `tags-ignore`, рабочий процесс не будет выполняться. Шаблоны, определенные в `branches` и `tags`, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда происходит событие `push`, если при этом не происходит событие `push` в:\n\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой соответствует `releases/**-alpha`, например `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`); \n* теге с именем `v2` (`refs/tags/v2`);\n* теге, имя которого начинается с `v1.`, например `v1.9` (`refs/tags/v1.9`).\n\n```yaml\non:\n push:\n # Sequence of patterns matched against refs/heads\n branches-ignore:\n - 'mona/octocat'\n - 'releases/**-alpha'\n # Sequence of patterns matched against refs/tags\n tags-ignore:\n - v2\n - v1.*\n```\n\n### Пример. Включение и исключение ветвей и тегов\n\nВы не можете использовать `branches` и `branches-ignore` для фильтрации одного и того же события в одном рабочем процессе. Аналогично, вы не можете использовать `tags` и `tags-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите одновременно включить и исключить шаблоны ветвей или тегов для одного события, используйте фильтр `branches` или `tags` с символом `!`, чтобы указать, какие ветви или теги следует исключить.\n\nЕсли вы определяете ветвь с символом `!`, необходимо также определить по крайней мере одну ветвь без символа `!`. Если вы хотите только исключить ветви, используйте вместо этого `branches-ignore`. Аналогично, если вы определяете тег с символом `!`, необходимо также определить по крайней мере один тег без символа `!`. Если вы хотите только исключить теги, используйте вместо этого `tags-ignore`.\n\nПорядок определения шаблонов имеет значение.\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает ссылку Git.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.\n\nСледующий рабочий процесс будет выполняться при отправке в `releases/10` или `releases/beta/mona`, но не в `releases/10-alpha` или `releases/beta/3-alpha`, потому что за положительным шаблоном следует отрицательный шаблон `!releases/**-alpha`. \n\n```yaml\non:\n push:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on..`\n\nПри использовании событий `push` и `pull_request` можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов.\n\nИспользуйте фильтр `paths`, если требуется включить шаблоны путей к файлам или одновременно включить и исключить их. Используйте фильтр `paths-ignore`, если требуется только исключить шаблоны путей к файлам. Для одного и того же события в рабочем процессе нельзя использовать фильтры `paths` и `paths-ignore` одновременно. Если вы хотите включить и исключить шаблоны путей для одного события, используйте `paths` префикс фильтра с `!` символом, чтобы указать, какие пути следует исключить.\n\n> \\[!NOTE]\n> Порядок определения `paths` шаблонов имеет значение:\n>\n> * Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает путь.\n> * Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.\n\nЕсли вы определили и `branches`/`branches-ignore`, и `paths`/`paths-ignore`, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `paths` и `paths-ignore` принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки `*` и `**`. Дополнительные сведения см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n### Пример. Включение путей\n\nЕсли хотя бы один путь соответствует шаблону в фильтре `paths`, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (`.js`).\n\n```yaml\non:\n push:\n paths:\n - '**.js'\n```\n\nЕсли рабочий процесс пропускается из-за фильтрации путей, [фильтрации](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ветвей или [сообщения](/ru/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии \"Ожидание\". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.\n\n### Пример. Исключение путей\n\nЕсли все имена путей соответствуют шаблонам в `paths-ignore`, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в `paths-ignore`, рабочий процесс запускается.\n\nРабочий процесс с приведенным ниже фильтром пути будет выполняться только при событиях `push` с по крайней мере одним файлом за пределами каталога `docs` в корне репозитория.\n\n```yaml\non:\n push:\n paths-ignore:\n - 'docs/**'\n```\n\n### Пример. Включение и исключение путей\n\nНельзя использовать `paths` и `paths-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте `paths` префикс фильтра с `!` символом, чтобы указать, какие пути следует исключить.\n\nЕсли вы определяете путь с символом `!`, необходимо также определить по крайней мере один путь без символа `!`. Если вы хотите только исключить пути, используйте вместо этого `paths-ignore`.\n\nПорядок определения `paths` шаблонов имеет значение:\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает путь.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.\n\nЭтот пример запускается каждый раз, когда событие `push` включает файл в каталоге `sub-project` или его подкаталогах, но не в каталоге `sub-project/docs`. Например, принудительная отправка с изменением `sub-project/index.js` или `sub-project/src/index.js` запустит выполнение рабочего процесса, но принудительная отправка, изменяющая только `sub-project/docs/readme.md`, не запустит его.\n\n```yaml\non:\n push:\n paths:\n - 'sub-project/**'\n - '!sub-project/docs/**'\n```\n\n### Сравнение различий в GIT\n\nФильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку `paths-ignore` или `paths`. Если измененных файлов нет, рабочий процесс не запускается.\n\nGitHub Создает список измененных файлов с помощью двухточийных диффов для отправки и трехточийных диффов для запросов на вытягивание:\n\n* **Запросы на вытягивание**. Различия с тремя точками — это сравнение последней версией тематической ветки с фиксацией, в которой тематическая ветка была в последний раз синхронизирована с основной ветвью.\n* **Отправки в существующие ветви**. Различие с двумя точками — это сравнение головных и базовых значений SHA непосредственно друг с другом.\n* **Отправки в новые ветви**. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации.\n\nВ некоторых ситуациях применяются ограничения, GitHub Actions которые изменяют способ выполнения фильтруемых рабочих процессов:\n\n* Если push-отправка содержит более 1000 фиксаций, рабочий процесс **всегда** будет выполняться.\n* При создании времени ожидания диффа рабочий процесс **всегда** будет выполняться.\n* Если созданный дифф содержит более 3000 файлов, а файлы, соответствующие фильтрам рабочих процессов, не находятся в первом 3000, возвращаемом фильтром, рабочий процесс **не** будет выполняться.\n\nЕсли вы наблюдаете это поведение, может потребоваться сделать фильтры более конкретными или изменить способ работы с push-отправками и запросами на вытягивание для создания более простых диффов.\n\nДополнительные сведения см. в разделе [Филиалы](/ru/pull-requests/reference/branches).\n\n## `on.schedule`\n\nС помощью `on.schedule` можно определить расписание рабочих процессов.\n\nИспользуйте [синтаксис POSIX cron](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) для планирования рабочих процессов в определённое время.\nПо умолчанию запланированные рабочие процессы выполняются в формате UTC. При необходимости можно указать часовой пояс с помощью [строки часового пояса IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) для. Запланированные рабочие процессы выполняются в последней фиксации на ветвь по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут.\n\n> \\[!NOTE]\n> Для расписаний, установленных `timezone` на часовой пояс, соблюдающий летнее время (DST), во время переходов на летнее время расписание в пропущенные часы перемещаются до следующего действительного времени. Например, расписание на 2:30 ночи переносится на 3:00 ночи.\n\nСинтаксис Cron содержит пять полей, разделенных пробелом, где каждое поле представляет единицу времени.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nЭти операторы можно использовать в любом из пяти полей:\n\n| Operator | Description | Пример |\n| ------------------------------------------------------------------------------------------------------ | --------------------------- | ------ |\n| \\* | Любое значение | |\n| `15 * * * *` запускается в каждую 15-ю минуту каждого часа каждого дня. | | |\n| , | Разделитель списка значений | |\n| `2,10 4,5 * * *` запускается во 2-ю и 10-ю минуты каждого 4-го и 5-го часов каждого дня. | | |\n| - | Диапазон значений | |\n| `30 4-6 * * *` запускается в 30-ю минуту каждого 4-го, 5-го и 6-го часов. | | |\n| / | Значения шага | |\n| `20/15 * * * *` запускается каждые 15 минут с 20-й по 59-ю минуту (в каждую 20-ю, 35-ю и 50-ю минуты). | | |\n\nВ этом примере рабочий процесс запускается в 5:30 утра в часовом поясе America/New\\_York каждый понедельник по пятницу:\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1-5'\n timezone: \"America/New_York\"\n```\n\nОдин рабочий процесс может запускаться несколькими событиями `schedule`. Доступ к событию `schedule` , активировав рабочему процессу через `github.event.schedule` контекст. В этом примере рабочий процесс запускается в 5:30 UTC каждый понедельник-четверг и 17:30 UTC во вторник и четверг, но пропускает `Not on Monday or Wednesday` шаг в понедельник и среду.\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1,3'\n - cron: '30 5,17 * * 2,4'\n\njobs:\n test_schedule:\n runs-on: ubuntu-latest\n steps:\n - name: Not on Monday or Wednesday\n if: github.event.schedule != '30 5 * * 1,3'\n run: echo \"This step will be skipped on Monday and Wednesday\"\n - name: Every time\n run: echo \"This step will always run\"\n```\n\nДополнительные сведения о событиях см. в `schedule` разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## `on.workflow_call`\n\nИспользуйте `on.workflow_call` для определения входных и выходных данных для многократно используемого рабочего процесса. Вы также можете сопоставить секреты, доступные для вызываемого рабочего процесса. Дополнительные сведения о повторно используемых рабочих процессах см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.inputs`\n\nПри использовании ключевого слова `workflow_call` можно дополнительно указать входные данные, передаваемые вызываемому рабочему процессу из вызывающего рабочего процесса. Дополнительные сведения о ключевом слове `workflow_call` см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call).\n\nПомимо доступных стандартных входных параметров `on.workflow_call.inputs` требует параметр `type`. Дополнительные сведения см. в разделе [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype).\n\nЕсли параметр `default` не задан, значение по умолчанию для входных данных — `false` для логического значения, `0` для числа и `\"\"` для строки.\n\nВ вызываемом рабочем процессе можно использовать контекст `inputs` для ссылки на входные данные. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#inputs-context).\n\nЕсли вызывающий рабочий процесс передает входные данные, которые не указаны в вызываемом рабочем процессе, это приведет к ошибке.\n\n### Пример `on.workflow_call.inputs`\n\n```yaml\non:\n workflow_call:\n inputs:\n username:\n description: 'A username passed from the caller workflow'\n default: 'john-doe'\n required: false\n type: string\n\njobs:\n print-username:\n runs-on: ubuntu-latest\n\n steps:\n - name: Print the input name to STDOUT\n run: echo The username is ${{ inputs.username }}\n```\n\nДополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.inputs..type`\n\nТребуется, если входные данные определены для ключевого слова `on.workflow_call`. Значение этого параметра — строка, указывающая тип входных данных. Должен иметь значение `boolean`, `number` или `string`.\n\n## `on.workflow_call.outputs`\n\nКарта выходных данных для вызываемого рабочего процесса. Выходные данные вызываемого рабочего процесса доступны для всех нижестоящих заданий в рабочем процессе вызывающего объекта. У каждых выходных данных есть идентификатор, необязательный `description,` и `value.` Для `value` необходимо задать значение выходных данных из задания в рамках вызываемого рабочего процесса.\n\nВ приведенном ниже примере для этого многократно используемого рабочего процесса определяются два набора выходных данных: `workflow_output1` и `workflow_output2`. Они сопоставляются с выходными данными `job_output1` и `job_output2` из вызываемого задания`my_job`.\n\n### Пример `on.workflow_call.outputs`\n\n```yaml\non:\n workflow_call:\n # Map the workflow outputs to job outputs\n outputs:\n workflow_output1:\n description: \"The first job output\"\n value: ${{ jobs.my_job.outputs.job_output1 }}\n workflow_output2:\n description: \"The second job output\"\n value: ${{ jobs.my_job.outputs.job_output2 }}\n```\n\nСведения о том, как ссылаться на выходные данные задания, см. в разделе [`jobs..outputs`](#jobsjob_idoutputs). Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.secrets`\n\nКарта секретов, которые можно использовать в вызываемом рабочем процессе.\n\nВ вызываемом рабочем процессе можно использовать контекст `secrets` для ссылки на секрет.\n\n> \\[!NOTE]\n> Если секрет передается в вложенный повторно используемый рабочий процесс, необходимо использовать [`jobs..secrets`](#jobsjob_idsecrets) еще раз для передачи секрета. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows#passing-secrets-to-nested-workflows).\n\nЕсли вызывающий рабочий процесс передает секрет, который не указан в вызываемом рабочем процессе, это приведет к ошибке.\n\n### Пример `on.workflow_call.secrets`\n\n```yaml\non:\n workflow_call:\n secrets:\n access-token:\n description: 'A token passed from the caller workflow'\n required: false\n\njobs:\n\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n # passing the secret to an action\n - name: Pass the received secret to an action\n uses: ./.github/actions/my-action\n with:\n token: ${{ secrets.access-token }}\n\n # passing the secret to a nested reusable workflow\n pass-secret-to-workflow:\n uses: ./.github/workflows/my-workflow\n secrets:\n token: ${{ secrets.access-token }}\n```\n\n## `on.workflow_call.secrets.`\n\nСтроковый идентификатор, связанный с секретом.\n\n## `on.workflow_call.secrets..required`\n\nЛогическое значение, указывающее, должен ли быть предоставлен секрет.\n\n## `on.workflow_run.`\n\nПри использовании события `workflow_run` можно указать, в каких ветвях должен выполняться запускающий рабочий процесс, чтобы активировать ваш рабочий процесс.\n\nВ фильтрах `branches` и `branches-ignore` можно использовать стандартные маски с такими символами, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\nНапример, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви, имя которой начинается с `releases/`.\n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches:\n - 'releases/**'\n```\n\nРабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви с именем отличным от `canary`.\n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches-ignore:\n - \"canary\"\n```\n\nДля одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр `branches` с символом `!`, чтобы указать, какие ветви следует исключить.\n\nПорядок определения шаблонов имеет значение.\n\n* Если после включающего шаблона идет исключающий (с префиксом `!`) и найдена ветвь, соответствующая им обоим, такая ветвь исключается.\n* Если после исключающего шаблона идет включающий, ветвь, соответствующая им обоим, снова включается.\n\nНапример, рабочий процесс со следующим триггером будет выполняться, если рабочий процесс с именем `Build` выполняется в ветви с именем `releases/10` или `releases/beta/mona`, но не в ветви `releases/10-alpha`, `releases/beta/3-alpha` или `main`. \n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.workflow_dispatch`\n\nПри использовании события `workflow_dispatch` можно дополнительно указать входные данные, передаваемые рабочему процессу.\n\nЭтот триггер получает события только в том случае, если файл рабочего процесса находится на ветвь по умолчанию.\n\n## `on.workflow_dispatch.inputs`\n\nАктивированный рабочий процесс получает входные данные в контексте `inputs`. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#inputs-context)\".\n\n> \\[!NOTE]\n>\n> * Рабочий процесс также получит входные данные в контексте `github.event.inputs` . Информация в контексте `inputs` и в контексте `github.event.inputs` идентична, за исключением того, что контекст `inputs` сохраняет логические значения в исходном формате логических значений, не преобразовывая их в строки. Тип `choice` разрешается в строку и является одним вариантом выбора.\n> * Максимальное количество свойств верхнего уровня для `inputs` — 25 .\n> * Максимальная полезная нагрузка составляет `inputs` 65 535 символов.\n\n### Пример `on.workflow_dispatch.inputs`\n\n```yaml\non:\n workflow_dispatch:\n inputs:\n logLevel:\n description: 'Log level'\n required: true\n default: 'warning'\n type: choice\n options:\n - info\n - warning\n - debug\n print_tags:\n description: 'True to print to STDOUT'\n required: true\n type: boolean\n tags:\n description: 'Test scenario tags'\n required: true\n type: string\n environment:\n description: 'Environment to run tests against'\n type: environment\n required: true\n\njobs:\n print-tag:\n runs-on: ubuntu-latest\n if: ${{ inputs.print_tags }} \n steps:\n - name: Print the input tag to STDOUT\n run: echo The tags are ${{ inputs.tags }} \n```\n\n## `on.workflow_dispatch.inputs..required`\n\nЛогическое значение, указывающее, нужно ли предоставлять входные данные.\n\n## `on.workflow_dispatch.inputs..type`\n\nЗначение этого параметра — строка, указывающая тип входных данных. Это должно быть одно из следующих: `boolean`, `choice``number``environment` или .`string`\n\n## `permissions`\n\n`permissions` можно использовать для изменения разрешений по умолчанию, предоставленных `GITHUB_TOKEN`, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе [Использование GITHUB\\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).\n\n`permissions` можно использовать в качестве ключа верхнего уровня для применения ко всем заданиям в рабочем процессе или в конкретных заданиях. При добавлении ключа `permissions` в конкретном задании указанные права доступа получают все действия и команды выполнения в этом задании, использующие `GITHUB_TOKEN`. Дополнительные сведения см. в разделе [`jobs..permissions`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions).\n\nВладельцы организации могут ограничить доступ на запись на `GITHUB_TOKEN` уровне репозитория. Дополнительные сведения см. в разделе [Отключение или ограничение GitHub Actions для вашей организации](/ru/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization) и .\n\nПри активации [`pull_request_target`](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target) рабочего процесса событием `GITHUB_TOKEN` предоставляется разрешение на чтение и запись репозитория, даже если он активируется из общедоступной вилки. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target).\n\nДля каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: `read` (если применимо), `write`или `none`.\n`write` включает в себя `read`. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение .\n\nДоступные разрешения и подробные сведения о том, что позволяет выполнять действие:\n\n| Разрешение | Разрешает действие с помощью `GITHUB_TOKEN` |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Работа с GitHub Actions. Например, `actions: write` позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). |\n| | |\n| `artifact-metadata` | Работа с метаданными артефактов. Например, `artifact-metadata: write` разрешает действие по созданию записей хранилища от имени артефакта сборки. Дополнительные сведения см. в разделе [Конечные точки REST API для метаданных артефактов](/ru/rest/orgs/artifact-metadata?apiVersion=2022-11-28). |\n| | |\n| | |\n| `attestations` | Работа с аттестациями артефактов. Например, `attestations: write` позволяет действию создать аттестацию артефактов для сборки. Дополнительные сведения см. в разделе [Использование аттестаций артефактов для установления происхождения сборок](/ru/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) |\n| | |\n| `checks` | Работа с проверками запусков и контрольных наборов. Например, `checks: write` позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). |\n| | |\n| `code-quality` | Работайте с качеством кода. Например, `code-quality: write` разрешает действовать по загрузке отчётов о покрытии кодов. Дополнительные сведения см. в разделе [Качество кода GitHub](/ru/code-security/concepts/code-quality/code-quality). |\n| | |\n| `contents` | Работа с содержимым репозитория. Например, `contents: read` позволяет действию перечислять фиксации и `contents: write` позволяет действию создавать выпуск. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). |\n| `deployments` | Работа с развертываниями. Например, `deployments: write` позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). |\n| `discussions` | Работа с обсуждениями GitHub. Например, `discussions: write` позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе [Использование API GraphQL для обсуждений](/ru/graphql/guides/using-the-graphql-api-for-discussions). |\n| | |\n| `id-token` | Получение маркера OpenID Connect (OIDC). Для этого требуется `id-token: write`. Дополнительные сведения см. в разделе [OpenID Connect](/ru/actions/concepts/security/openid-connect#updating-your-workflows-for-oidc) |\n| | |\n| `issues` | Работа с проблемами. Например, `issues: write` позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). |\n| `packages` | Работа с пакетами GitHub. Например, `packages: write` позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе [Сведения о разрешениях для пакетов GitHub](/ru/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). |\n| `pages` | Работа с GitHub Pages. Например, `pages: write` позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). |\n| `pull-requests` | Работа с запросами на вытягивание. Например, `pull-requests: write` позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). |\n| `security-events` | Работа с оповещениями проверки кода GitHub. Например, `security-events: read` позволяет действию выводить список оповещений сканирования кода для репозитория и `security-events: write` позволяет действию обновлять состояние оповещений сканирования кода. Для получения дополнительной информации [смотрите раздел разрешений репозитория для раздела «Уведомления о сканировании кода».](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

|\n| Для оповещений Dependabot используйте разрешение `vulnerability-alerts` . Уведомления о секретном сканировании нельзя читать с этим разрешением и требуют приложения GitHub или .personal access token Для получения дополнительной информации см. [раздел «Разрешения репозитория для «Секретные уведомления о сканировании»](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) в разделе «Разрешения, необходимые для приложений GitHub». | |\n| `statuses` | Работа с состояниями фиксации. Например, `statuses:read` позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). |\n| | |\n| `vulnerability-alerts` | Читайте оповещения Dependabot. Например, `vulnerability-alerts: read` позволяет выполнять действие для перечисления оповещений Dependabot для репозитория. Только `read` и `none` поддерживаются; `write` не является действительным. Когда `write-all` используется или `read-all` — `vulnerability-alerts` автоматически включается как `read`. Для получения дополнительной информации см. [раздел «Разрешения репозитория» для «Dependabot alerts](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts)». |\n| | |\n\n### Определение доступа для `GITHUB_TOKEN` областей\n\nВы можете определить доступ, который `GITHUB_TOKEN` будет разрешен, указав `read`или `write``none` как значение доступных разрешений в `permissions` ключе.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n code-quality: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nЕсли указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение .\n\nДля определения одного из `read-all``write-all` доступных разрешений можно использовать следующий синтаксис:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nДля отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:\n\n```yaml\npermissions: {}\n```\n\n#### Изменение разрешений в вилку репозитория\n\nС помощью ключа `permissions` можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n### Как вычисляются разрешения для задания рабочего процесса\n\nИзначально в качестве разрешений для `GITHUB_TOKEN` задаются параметры по умолчанию для предприятия, организации или репозитория. Если на любом из этих уровней по умолчанию заданы ограниченные разрешения, они будут применяться к соответствующим репозиториям. Например, если выбрать в качестве значения по умолчанию на уровне организации ограниченные разрешения, все репозитории в этой организации будут использовать в качестве значения по умолчанию ограниченные разрешения. Затем разрешения корректируются на основе любой конфигурации в файле рабочего процесса: сначала на уровне рабочего процесса, а затем на уровне задания. Наконец, если рабочий процесс был запущен событием pull request, отличным `pull_request_target` от форкированного репозитория, и **токены Send write to workflows из настройки pull** requests не выбраны, права на запись изменяются на только чтение.\n\n### `GITHUB_TOKEN` Настройка разрешений для всех заданий в рабочем процессе\n\nМожно указать `permissions` на верхнем уровне рабочего процесса, чтобы параметр применялось ко всем заданиям в рабочем процессе.\n\n#### Пример. Настройка `GITHUB_TOKEN` разрешений для всего рабочего процесса\n\nВ этом примере показаны разрешения, заданные для `GITHUB_TOKEN`, которые будут применены ко всем заданиям в рабочем процессе. Всем разрешениям предоставляется доступ на чтение.\n\n```yaml\nname: \"My workflow\"\n\non: [ push ]\n\npermissions: read-all\n\njobs:\n ...\n```\n\n### `permissions` Использование ключа для вилированных репозиториев\n\nКлюч можно использовать `permissions` для добавления и удаления `read` разрешений для вилированных репозиториев, но обычно невозможно предоставить `write` доступ. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n### Права на запуски рабочих процессов, вызываемые Dependabot\n\nРабочие процессы запускаются запросами Dependabot на вытягивание, как если бы они были из вилированного репозитория, поэтому используйте только `GITHUB_TOKEN`для чтения. Этот рабочий процесс не может получить доступ к секретам. Сведения о стратегиях защиты этих рабочих процессов см. в разделе [Справочник по безопасному использованию](/ru/actions/reference/security/secure-use).\n\n## `env`\n\nПеременные `map` , доступные для шагов всех заданий в рабочем процессе. Можно также задать переменные, доступные только для шагов одного задания или на одном шаге. Дополнительные сведения см. в разделах [`jobs..env`](#jobsjob_idenv) и [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nПеременные на схеме `env` не могут быть определены с точки зрения других переменных на карте.\n\nПри определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.\n\n### Пример `env`\n\n```yaml\nenv:\n SERVER: production\n```\n\n## `defaults`\n\nИспользуйте `defaults` для создания `map` с параметрами по умолчанию, которые будут применяться ко всем заданиям в рабочем процессе. Можно также указать параметры по умолчанию, доступные только для задания. Дополнительные сведения см. в разделе [`jobs..defaults`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaults).\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `defaults.run`\n\nМожно использовать `defaults.run` для указания параметров по умолчанию `shell` и `working-directory` для всех этапов [`run`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) в рабочем процессе. Можно также указать параметры по умолчанию для `run`, доступные только для задания. Дополнительные сведения см. в разделе [`jobs..defaults.run`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun). В этом ключевом слове нельзя использовать контексты или выражения.\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n### Пример. Указание оболочки по умолчанию и рабочего каталога\n\n```yaml\ndefaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `defaults.run.shell`\n\nИспользуется `shell` для определения `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#context-availability)\".\n\n| Поддерживаемая платформа | `shell` параметр | Description | Выполнение команды внутри системы |\n| ------------------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- |\n| Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать `bash` явно. Если `bash` не удается найти в пути, выполняется обработка в качестве `sh`. | `bash -e {0}` |\n| Все | `bash` | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом `sh`. При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Все | `pwsh` | PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. | `pwsh -command \". '{0}'\"` |\n| Все | `python` | Выполняет команду Python. | `python {0}` |\n| Linux / macOS | `sh` | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и `bash` не найден в пути. | `sh -e {0}` |\n| Windows | `cmd` | GitHub добавляет расширение `.cmd` к имени скрипта и заменяет `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. Если в локальном средстве выполнения Windows не установлен *PowerShell Core*, будет использоваться *PowerShell Desktop*. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub добавляет расширение `.ps1` к имени скрипта. | `powershell -command \". '{0}'\"`. |\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `defaults.run.working-directory`\n\nИспользуется `working-directory` для определения рабочего каталога для `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#context-availability)\".\n\n> \\[!TIP]\n> Перед запуском оболочки убедитесь, что `working-directory` назначаемая функция существует в средстве выполнения.\n> Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `concurrency`\n\nИспользуйте `concurrency`, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Выражение может использовать `github`[](/ru/actions/reference/workflows-and-actions/contexts#github-context)только контекст и контексты. Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\nТакже можно задать `concurrency` на уровне задания. Дополнительные сведения см. в разделе [`jobs..concurrency`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency).\n\nЭто означает, что в группе одновременно может быть максимум одна работающая задача или рабочий процесс. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут `pending`. По умолчанию любая существующая `pending` задача или рабочий процесс в той же группе параллелизма будет отменена, и на её место займёт новая очередная задача или рабочий процесс.\n\nЧтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите `cancel-in-progress: true`. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать `cancel-in-progress` как выражение с любым из контекстов разрешенного выражения.\n\nЧтобы позволить `pending` нескольким задачам или рабочим процессам ожидать в одной группе параллелизма, используйте опциональное `queue` свойство. Свойство `queue` принимает следующие значения:\n\n* `single` (по умолчанию): В группе параллелизма может `pending` находиться максимум одна задача или запуск рабочего процесса. Когда новая задача или рабочий процесс ставится в очередь, любая существующая `pending` задача или рабочий процесс, запущенный в той же группе, отменяется и заменяется.\n* `max`: В группе параллелизма может `pending` быть до 100 заданий или запусков рабочих процессов. Когда очередь заполнена, любые дополнительные задания или запуски рабочих процессов отменяются.\n\nКомбинация `queue: max` и `cancel-in-progress: true` не допускается и приведёт к ошибке валидации рабочего процесса.\n\n> \\[!NOTE]\n>\n> * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма.\n> * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется.\n\n### Пример. Использование параллелизма и поведения по умолчанию\n\nПо умолчанию GitHub Actions режим позволяет выполнять несколько заданий или рабочих процессов одновременно. Ключевое `concurrency` слово позволяет управлять параллелизмом выполнения рабочих процессов.\n\nНапример, ключевое `concurrency` слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nКроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью `concurrency` ключевого слова на уровне задания:\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Пример: группы параллелизма\n\nГруппы параллелизма предоставляют способ управления выполнением и ограничением выполнения выполнения рабочих процессов или заданий, использующих один и тот же ключ параллелизма.\n\nКлюч `concurrency` используется для группировки рабочих процессов или заданий в группу параллелизма. Когда вы определяете ключ `concurrency` , GitHub Actions убедитесь, что в любой момент времени работает только один рабочий процесс или задание с этим ключом. Если новый рабочий процесс или задание начинается с того же `concurrency` ключа, GitHub Actions все рабочие процессы или задания с этим ключом отменяются. Ключ `concurrency` может быть жестко закодированной строкой или может быть динамическим выражением, которое включает в себя переменные контекста.\n\nМожно определить условия параллелизма в рабочем процессе, чтобы рабочий процесс или задание были частью группы параллелизма.\n\nЭто означает, что при запуске или запуске рабочего процесса GitHub отменяет все запуски рабочих процессов или задания, которые уже выполняются в той же группе параллелизма. Это полезно в сценариях, в которых требуется предотвратить параллельные запуски для определенного набора рабочих процессов или заданий, таких как те, которые используются для развертываний в промежуточной среде, чтобы предотвратить действия, которые могут вызвать конфликты или использовать больше ресурсов, чем необходимо.\n\nВ этом примере `job-1` является частью группы параллелизма с именем `staging_environment`. Это означает, что если запускается новый запуск `job-1` , все запуски того же задания в `staging_environment` группе параллелизма, которые уже выполняются, будут отменены.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nКроме того, использование динамического выражения, например `concurrency: ci-${{ github.ref }}` в рабочем процессе, означает, что рабочий процесс или задание будет частью группы `ci-` параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Пример: очередь на несколько ожидающих запусков\n\nПо умолчанию в группе параллелизма может `pending` находиться только одна задача или запуск рабочего процесса. Чтобы позволить несколько забегов выстраиваться в очередь вместо отмены, установите `queue: max`. При `queue: max`, до 100 заданий или запусков рабочих процессов могут подождать в группе параллелизма; после заполнения очереди любые дополнительные запуски отменяются.\n\nНапример, следующие рабочие процессы ставят в очередь развертывания в `production` среду, обрабатывая их по одному в порядке в зависимости от того, когда каждый запуск начинал ожидание группы параллелизма:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nОбратите внимание, что `queue: max` нельзя комбинировать с `cancel-in-progress: true`, поскольку оба варианта описывают противоречивые действия при обработке запусков в процессе.\n\n### Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска\n\nЧтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать `concurrency` ключ с опцией`true`:`cancel-in-progress`\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nОбратите внимание, что в этом примере, без определения конкретной группы параллелизма, GitHub Actions\\_будет отменён любой\\_ текущий запуск задания или рабочего процесса.\n\n### Пример. Использование резервного значения\n\nЕсли вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, `github.head_ref` определяется только для событий `pull_request`. Если рабочий процесс реагирует на другие события в дополнение к событиям `pull_request`, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях `pull_request`. Если параметр `github.head_ref` не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса\n\nПри наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса.\n\nЧтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство `github.workflow` для создания группы параллелизма:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий в определенных ветвях\n\nЕсли вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с `cancel-in-progress`. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.\n\nЧтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать `cancel-in-progress` выражение, аналогичное следующему:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nВ этом примере несколько push-уведомлений в `release/1.2.3` ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например `main`, отменяет выполняемые запуски.\n\n## `jobs`\n\nЗапуск рабочего процесса состоит из одного или нескольких `jobs`, которые по умолчанию выполняются параллельно. Для последовательного выполнения заданий можно определить зависимости в других заданиях с помощью ключевого слова `jobs..needs`.\n\nКаждое задание выполняется в среде средства выполнения тестов, указанной в параметре `runs-on`.\n\nВы можете выполнять неограниченное количество заданий, если вы не превышаете лимиты по использованию рабочих процессов. Для получения дополнительной информации см. [Выставление счетов и использование](/ru/actions/concepts/billing-and-usage) для GitHub-hosted runners и [Ограничения действий](/ru/actions/reference/limits) для самостоятельных ограничений использования бегунов.\n\nЕсли вам нужно найти уникальный идентификатор задания, выполняющегося в рабочем процессе, можно использовать GitHub API. Дополнительные сведения см. в разделе [REST API endpoints для GitHub Actions](/ru/rest/actions#workflow-jobs).\n\n## `jobs.`\n\nИспользуйте `jobs.`, чтобы назначить заданию уникальный идентификатор. Ключ `job_id` представляет собой строку, а значение ключа представляет собой карту данных конфигурации задания. Необходимо заменить `` строкой, уникальной для объекта `jobs`. `` должен начинаться с буквы или `_` и может включать только буквенно-цифровые символы `-` или `_`.\n\n### Пример. Создание заданий\n\nВ этом примере были созданы два задания, и их `job_id` равны `my_first_job` и `my_second_job`.\n\n```yaml\njobs:\n my_first_job:\n name: My first job\n my_second_job:\n name: My second job\n```\n\n## `jobs..name`\n\nИспользуйте `jobs..name` для присвоения имени заданию, которое отображается в пользовательском интерфейсе GitHub.\n\n## `jobs..permissions`\n\nДля определенного задания `jobs..permissions` можно использовать для изменения разрешений по умолчанию, предоставленных `GITHUB_TOKEN`, при необходимости добавляя или удаляя права доступа, чтобы разрешить только минимальный требуемый доступ. Дополнительные сведения см. в разделе [Использование GITHUB\\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).\n\nУказав разрешение в определении задания, при необходимости можно настроить для каждого задания другой набор разрешений для `GITHUB_TOKEN`. Кроме того, можно указать разрешения для всех заданий в рабочем процессе. Сведения об определении разрешений на уровне рабочего процесса см. в разделе [`permissions`](/ru/actions/reference/workflows-and-actions/workflow-syntax#permissions).\n\nДля каждого из доступных разрешений, показанных в таблице ниже, можно назначить один из уровней доступа: `read` (если применимо), `write`или `none`.\n`write` включает в себя `read`. Если указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение .\n\nДоступные разрешения и подробные сведения о том, что позволяет выполнять действие:\n\n| Разрешение | Разрешает действие с помощью `GITHUB_TOKEN` |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Работа с GitHub Actions. Например, `actions: write` позволяет действию отменить выполнение рабочего процесса. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). |\n| | |\n| `artifact-metadata` | Работа с метаданными артефактов. Например, `artifact-metadata: write` разрешает действие по созданию записей хранилища от имени артефакта сборки. Дополнительные сведения см. в разделе [Конечные точки REST API для метаданных артефактов](/ru/rest/orgs/artifact-metadata?apiVersion=2022-11-28). |\n| | |\n| | |\n| `attestations` | Работа с аттестациями артефактов. Например, `attestations: write` позволяет действию создать аттестацию артефактов для сборки. Дополнительные сведения см. в разделе [Использование аттестаций артефактов для установления происхождения сборок](/ru/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) |\n| | |\n| `checks` | Работа с проверками запусков и контрольных наборов. Например, `checks: write` позволяет действию создать выполнение проверки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). |\n| | |\n| `code-quality` | Работайте с качеством кода. Например, `code-quality: write` разрешает действовать по загрузке отчётов о покрытии кодов. Дополнительные сведения см. в разделе [Качество кода GitHub](/ru/code-security/concepts/code-quality/code-quality). |\n| | |\n| `contents` | Работа с содержимым репозитория. Например, `contents: read` позволяет действию перечислять фиксации и `contents: write` позволяет действию создавать выпуск. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). |\n| `deployments` | Работа с развертываниями. Например, `deployments: write` позволяет действию создать новое развертывание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). |\n| `discussions` | Работа с обсуждениями GitHub. Например, `discussions: write` позволяет действию закрыть или удалить обсуждение. Дополнительные сведения см. в разделе [Использование API GraphQL для обсуждений](/ru/graphql/guides/using-the-graphql-api-for-discussions). |\n| | |\n| `id-token` | Получение маркера OpenID Connect (OIDC). Для этого требуется `id-token: write`. Дополнительные сведения см. в разделе [OpenID Connect](/ru/actions/concepts/security/openid-connect#updating-your-workflows-for-oidc) |\n| | |\n| `issues` | Работа с проблемами. Например, `issues: write` позволяет действию добавить комментарий к проблеме. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). |\n| `packages` | Работа с пакетами GitHub. Например, `packages: write` позволяет действию отправлять и публиковать пакеты в пакетах GitHub. Дополнительные сведения см. в разделе [Сведения о разрешениях для пакетов GitHub](/ru/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). |\n| `pages` | Работа с GitHub Pages. Например, `pages: write` позволяет действию запрашивать сборку GitHub Pages. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). |\n| `pull-requests` | Работа с запросами на вытягивание. Например, `pull-requests: write` позволяет действию добавить метку в запрос на вытягивание. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). |\n| `security-events` | Работа с оповещениями проверки кода GitHub. Например, `security-events: read` позволяет действию выводить список оповещений сканирования кода для репозитория и `security-events: write` позволяет действию обновлять состояние оповещений сканирования кода. Для получения дополнительной информации [смотрите раздел разрешений репозитория для раздела «Уведомления о сканировании кода».](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

|\n| Для оповещений Dependabot используйте разрешение `vulnerability-alerts` . Уведомления о секретном сканировании нельзя читать с этим разрешением и требуют приложения GitHub или .personal access token Для получения дополнительной информации см. [раздел «Разрешения репозитория для «Секретные уведомления о сканировании»](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) в разделе «Разрешения, необходимые для приложений GitHub». | |\n| `statuses` | Работа с состояниями фиксации. Например, `statuses:read` позволяет действию выводить список состояний фиксации для указанной ссылки. Дополнительные сведения см. в разделе [Для приложений GitHub требуются права](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). |\n| | |\n| `vulnerability-alerts` | Читайте оповещения Dependabot. Например, `vulnerability-alerts: read` позволяет выполнять действие для перечисления оповещений Dependabot для репозитория. Только `read` и `none` поддерживаются; `write` не является действительным. Когда `write-all` используется или `read-all` — `vulnerability-alerts` автоматически включается как `read`. Для получения дополнительной информации см. [раздел «Разрешения репозитория» для «Dependabot alerts](/ru/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts)». |\n| | |\n\n### Определение доступа для `GITHUB_TOKEN` областей\n\nВы можете определить доступ, который `GITHUB_TOKEN` будет разрешен, указав `read`или `write``none` как значение доступных разрешений в `permissions` ключе.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n code-quality: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nЕсли указать доступ для любого из этих разрешений, то для всех этих разрешений задано `none`значение .\n\nДля определения одного из `read-all``write-all` доступных разрешений можно использовать следующий синтаксис:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nДля отключения разрешений для всех доступных разрешений можно использовать следующий синтаксис:\n\n```yaml\npermissions: {}\n```\n\n#### Изменение разрешений в вилку репозитория\n\nС помощью ключа `permissions` можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключение из этого поведения — когда администратор-пользователь выбрал **токены «Отправить токены записи в рабочие процессы» из опции pull** requests в GitHub Actions настройках. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n#### Пример. Настройка `GITHUB_TOKEN` разрешений для одного задания в рабочем процессе\n\nВ этом примере показаны разрешения, заданные для задания `GITHUB_TOKEN`, которое будет применяться только к заданию с именем `stale`. Доступ на запись предоставляется для `issues` разрешений и `pull-requests` разрешений. Все остальные разрешения не будут иметь доступа.\n\n```yaml\njobs:\n stale:\n runs-on: ubuntu-latest\n\n permissions:\n issues: write\n pull-requests: write\n\n steps:\n - uses: actions/stale@v10\n```\n\n## `jobs..needs`\n\nИспользуйте `jobs..needs` для определения всех заданий, которые должны быть успешно завершены перед выполнением этого задания. Это может быть строка или массив строк. Если задание завершается ошибкой или пропускается, все задания, необходимые для него, пропускаются, если задания не используют условное выражение, которое приводит к продолжению задания. Если выполнение содержит ряд заданий, которые нуждаются друг в другом, сбой или пропуск применяется ко всем заданиям в цепочке зависимостей из точки сбоя или пропускания. Если вы хотите выполнить задание, даже если задание зависит от не удалось, используйте условное `always()` выражение в `jobs..if`.\n\n### Пример. Необходимо успешное выполнение зависимых заданий\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n needs: [job1, job2]\n```\n\nВ этом примере задание `job1` должно успешно завершить работу перед началом задания `job2`, а задание `job3` ожидает завершения заданий `job1` и `job2`.\n\nЗадания в этом примере выполняются последовательно:\n\n1. `job1`\n2. `job2`\n3. `job3`\n\n### Пример. Успешное выполнение зависимых заданий не требуется\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n if: ${{ always() }}\n needs: [job1, job2]\n```\n\nВ этом примере в задании `job3` используется условное выражение `always()`, чтобы оно всегда выполнялось после завершения выполнения заданий `job1` и `job2`, независимо от того, завершились ли они успешно. Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions#status-check-functions).\n\n## `jobs..if`\n\nУсловное выражение `jobs..if` можно использовать для предотвращения выполнения задания, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#context-availability).\n\n> \\[!NOTE]\n> Условие `jobs..if` вычисляется перед [`jobs..strategy.matrix`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymatrix) применением.\n\nПри использовании выражений в условном `if` режиме можно, при необходимости, опустить синтаксис выражения `${{ }}`, так как GitHub Actions автоматически вычисляет условное `if` выражение как выражение. Однако это исключение не применяется везде.\n\nВсегда следует использовать синтаксис выражения `${{ }}`концевого выражения %} или экранировать с `''`, `\"\"`либо `()` когда выражение начинается с `!`, так как `!` зарезервировано нотация в формате YAML. Например:\n\n{% raw %}\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nДля получения дополнительной информации см. [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\n### Пример. Выполнение задания только для определенного репозитория\n\nВ этом примере используется `if` для управления выполнением задания `production-deploy`. Оно будет выполняться только в том случае, если репозиторий имеет имя `octo-repo-prod` и находится в организации `octo-org`. В противном случае задание будет отмечено как *пропущенное*.\n\n```yaml copy\nname: example-workflow\non: [push]\njobs:\n production-deploy:\n if: github.repository == 'octo-org/octo-repo-prod'\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n```\n\n## `jobs..runs-on`\n\nИспользуйте `jobs..runs-on` для определения типа компьютера, на котором будет запускаться задание.\n\n* Машина назначения может быть либо [GitHub-hosted runner](#choosing-github-hosted-runners)[крупное средство выполнения](#choosing-runners-in-a-group), либо [самостоятельным](#choosing-self-hosted-runners).\n\n* Вы можете нацеливать бегуна на основе меток, назначенных им, или их членства в группах или сочетания этих.\n\n* Вы можете предоставить следующие возможности `runs-on` :\n * Одна строка\n * Одна переменная, содержащая строку\n * Массив строк, переменных, содержащих строки, или сочетание обоих\n * `key: value` Пара с помощью клавиш или `group` ключей `labels`\n\n* При указании массива строк или переменных рабочий процесс будет выполняться на любом средстве выполнения, который соответствует всем указанным `runs-on` значениям. Например, здесь задание будет выполняться только на локальном runner с метками `linux`и`x64``gpu`:\n\n ```yaml\n runs-on: [self-hosted, linux, x64, gpu]\n ```\n\n Дополнительные сведения см. в разделе [\"Выбор локальных](#choosing-self-hosted-runners) средств выполнения\".\n\n* Строки и переменные можно смешивать в массиве. Например:\n\n ```yaml\n on:\n workflow_dispatch:\n inputs:\n chosen-os:\n required: true\n type: choice\n options:\n - Ubuntu\n - macOS\n\n jobs:\n test:\n runs-on: [self-hosted, \"${{ inputs.chosen-os }}\"]\n steps:\n - run: echo Hello world!\n ```\n\n* Если необходимо запустить рабочий процесс на нескольких компьютерах, используйте [`jobs..strategy`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy).\n\n> \\[!NOTE]\n> Кавычки не требуются вокруг простых строк, таких `self-hosted`как , но они необходимы для выражений вроде`\"${{ inputs.chosen-os }}\"` .\n\n### Выбор GitHubведущих бегунов\n\nЕсли вы используете GitHub-hosted runner, каждая задача запускается в новом экземпляре изображения раннера, заданного .`runs-on`\n\nЦенность runs-on, когда вы используете GitHub-hosted runner, — это метка рабочего процесса или название группы бегущих. Метки для стандартных GitHub-hosted бегунов показаны в следующих таблицах.\n\nДополнительные сведения см. в разделе [Средства выполнения тестов, размещенные в GitHub](/ru/actions/concepts/runners/github-hosted-runners).\n\n### Стандартные GitHubразмещённые раннеры для публичных репозиториев\n\nДля общедоступных репозиториев задания с метками рабочего процесса, показанными в таблице ниже, будут выполняться с соответствующими спецификациями.\nЗа исключением средств выполнения тестов с одним процессором, каждое средство выполнения GitHub-hosted является новой виртуальной машиной (VM), размещенной в GitHub. Single-CPU средства выполнения тестов размещаются в контейнере на общей виртуальной машине — см. [раздел AUTOTITLE](/ru/actions/reference/runners/github-hosted-runners#single-cpu-runners). Использование стандартных GitHub-hosted runners бесплатно и неограничено на публичных репозиториях.\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n\n
\nВиртуальная машина / контейнер\nПроцессор (ЦП)\nПамять (ОЗУ)\nХранилище (SSD)архитектура \nМетка рабочего процесса
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux416 ГБ14 ГБ x64 \n\n```\n ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 , (Общедоступная предварительная версия)
Windows416 ГБ14 ГБ x64 \n \n windows-latest, , windows-2025windows-2025-vs2026windows-2022
Linux416 ГБ14 ГБ arm64 \n \n ubuntu-24.04-arm, , ubuntu-22.04-armubuntu-26.04-arm (Общедоступная предварительная версия)
Windows416 ГБ14 ГБarm64\n \n windows-11-arm, windows-11-vs2026-arm
macOS414 ГБ14 ГБ Intel \n \n macos-15-intel, macos-26-intel
macOS3 (М1)7 ГБ14 ГБ arm64 \n \n macos-latest, macos-14, macos-15macos-26xcode-27 ()Общедоступная предварительная версия
\n\n### Стандартные GitHub-hosted раннеры для приватных репозиториев\n\nДля приватных репозиториев задания с метками рабочих процессов, показанных в таблице ниже, будут выполняться на виртуальных машинах с соответствующими спецификациями. Эти участники используют выделенные бесплатные минуты вашего GitHub аккаунта и затем взимают плату по ставке за минуту. См [. раздел AUTOTITLE](/ru/billing/reference/actions-runner-pricing).\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n
\nвиртуальная машина\nПроцессор (ЦП)\nПамять (ОЗУ)\nХранилище (SSD)архитектура \nМетка рабочего процесса
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux28 ГБ14 ГБ x64 \n\n```\n ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 , (Общедоступная предварительная версия)
Windows28 ГБ14 ГБ x64 \n \n windows-latest, , windows-2025windows-2022
Linux28 ГБ14 ГБ arm64 \n \n ubuntu-24.04-arm, , ubuntu-22.04-armubuntu-26.04-arm (Общедоступная предварительная версия)
Windows28 ГБ14 ГБ arm64 \n \n windows-11-arm, windows-11-vs2026-arm
macOS414 ГБ14 ГБ Intel \n \n macos-15-intel, macos-26-intel
macOS3 (М1)7 ГБ14 ГБ arm64 \n \n macos-latest, macos-14, macos-15macos-26xcode-27 ()Общедоступная предварительная версия
\n\nПомимо стандартных GitHubразмещённых раннеров, GitHub клиентам предлагают GitHub Team и GitHub Enterprise Cloud планируют различные управляемые виртуальные машины с расширенными функциями — например, большим количеством ядер и дискового пространства, машины с GPU и ARM. Дополнительные сведения см. в разделе [Более крупные бегуны](/ru/actions/concepts/runners/larger-runners).\n\n> \\[!NOTE]\n> Раннер-образы `-latest` — это самые свежие стабильные образы, которые GitHub предоставляют, а возможно, и не являются самой новой версией операционной системы, доступной у поставщика операционной системы.\n\n> \\[!WARNING]\n> Образы бета-версии и устаревшие предоставляются как есть, \"со всеми сбоями\" и \"как доступны\" и исключены из соглашения об уровне обслуживания и гарантии. Для образов бета-версий может не оказываться поддержка.\n\n#### Пример: указание операционной системы\n\n```yaml\nruns-on: ubuntu-latest\n```\n\nДополнительные сведения см. в разделе [Средства выполнения тестов, размещенные в GitHub](/ru/actions/concepts/runners/github-hosted-runners).\n\n### Выбор локальных средств выполнения тестов\n\nЧтобы указать локальное средство выполнения тестов для задания, настройте `runs-on` в файле рабочего процесса, используя метки локального средства выполнения тестов.\n\nУ локальных модулей выполнения может быть `self-hosted` метка. При настройке локального runner по умолчанию мы будем включать метку `self-hosted`. Вы можете передать `--no-default-labels` флаг, чтобы предотвратить применение локальной метки. Метки можно использовать для создания параметров целевого назначения для средств выполнения, таких как операционная система или архитектура, мы рекомендуем предоставить массив меток, начинающихся с `self-hosted` (это должно быть указано сначала), а затем включить дополнительные метки по мере необходимости. При указании массива меток задания будут помещены в очередь в средства выполнения тестов, которые имеют все указанные метки.\n\n> \\[!NOTE] Actions Runner Controller не поддерживает эту `self-hosted` метку.\n\n#### Пример: использование меток для выбора средства выполнения тестов\n\n```yaml\nruns-on: [self-hosted, linux]\n```\n\nДополнительные сведения см. в разделе \\[AUTOTITLE и [Локальные средства выполнения тестов](/ru/actions/concepts/runners/self-hosted-runners)]\\(/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow).\n\n### Выбор бегуна в группе\n\nВы можете использовать `runs-on` для целевых групп runner, чтобы задание выполнялось на любом средстве выполнения, являющегося членом этой группы. Для более детального управления можно также объединить группы runner с метками.\n\nГруппы runner могут иметь [крупное средство выполнениятолько локальные или](/ru/actions/concepts/runners/larger-runners)[локальные модули выполнения](/ru/actions/how-tos/manage-runners/self-hosted-runners) в качестве членов.\n\n#### Пример. Использование групп для управления выполнением заданий\n\nВ этом примере бегунки были добавлены в группу под названием `build-runners`. Ключ `runs-on` отправляет задание любому доступному `build-runners` средству выполнения в группе:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on: \n group: build-runners\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n#### Пример. Объединение групп и меток\n\nПри сочетании групп и меток средство выполнения должно соответствовать обоим требованиям, чтобы иметь право на выполнение задания.\n\nВ этом примере `runs-on` ключ объединяется `group` так `labels` , что задание направляется к любому доступному бегущему в группе, который также имеет совпадающую метку:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on:\n group: ubuntu-runners\n labels: ubuntu-24.04-16core\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n## `jobs..snapshot`\n\nВы можете использовать `jobs..snapshot` его для создания пользовательского изображения.\n\nДобавьте ключевое слово snapshot в задание, используя либо строковый синтаксис, либо синтаксис сопоставления, как показано в [разделе Создание пользовательского изображения](/ru/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image).\n\nКаждое задание, включающее ключевое слово snapshot, создает отдельное изображение. Чтобы создать только одно изображение или версию изображения, включите все шаги рабочего процесса в одно задание. При каждом успешном выполнении задания, содержащего ключевое слово snapshot, создается новая версия этого изображения.\n\nДополнительные сведения см. в разделе [Использование пользовательских изображений](/ru/actions/how-tos/manage-runners/larger-runners/use-custom-images).\n\n## `jobs..environment`\n\nИспользуется `jobs..environment` для определения среды, на которую ссылается задание.\n\nВы можете указать среду в виде только имени среды `name` или в виде объекта среды с `name` и `url`. URL-адрес сопоставляется с `environment_url` в API развертываний. Дополнительные сведения об API развертываний см. в разделе [Конечные точки REST API для репозиториев](/ru/rest/repos#deployments).\n\n> \\[!NOTE]\n> Все правила защиты развертывания должны передаваться перед отправкой задания, ссылающегося на среду, в средство выполнения. Дополнительные сведения см. в разделе [Управление средами для развертывания](/ru/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\n### Пример. Использование только имени среды\n\n```yaml\nenvironment: staging_environment\n```\n\n### Пример. Использование имени среды и URL-адреса\n\n```yaml\nenvironment:\n name: production_environment\n url: https://github.com\n```\n\nЗначение `url` может быть выражением. Контексты разрешенных выражений: [`github`](/ru/actions/reference/workflows-and-actions/contexts#github-context), \\[[`inputs``job``runner`](/ru/actions/reference/workflows-and-actions/contexts#runner-context)`env`]\\(/actions/reference/workflows-and-actions/contexts#env-context)и .[`steps`](/ru/actions/reference/workflows-and-actions/contexts#steps-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\n### Пример. Использование выходных данных в качестве URL-адреса\n\n```yaml\nenvironment:\n name: production_environment\n url: ${{ steps.step_id.outputs.url_output }}\n```\n\nЗначение `name` может быть выражением. Контексты разрешенных выражений: `github`[](/ru/actions/reference/workflows-and-actions/contexts#github-context),`inputs`[](/ru/actions/reference/workflows-and-actions/contexts#inputs-context) , `vars`[](/ru/actions/reference/workflows-and-actions/contexts#vars-context),`needs`[](/ru/actions/reference/workflows-and-actions/contexts#needs-context) ,`strategy`[](/ru/actions/reference/workflows-and-actions/contexts#strategy-context) и .[`matrix`](/ru/actions/reference/workflows-and-actions/contexts#matrix-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\n### Пример. Использование выражения в качестве имени среды\n\n```yaml\nenvironment:\n name: ${{ github.ref_name }}\n```\n\n### Пример. Использование среды без создания развертывания\n\nУстановите `deployment` для `false` использования секретов и переменных среды без создания объекта развертывания.\n\n```yaml\nenvironment:\n name: testing\n deployment: false\n```\n\nПараметр `deployment: false` не совместим с пользовательскими правилами защиты развертывания.\nДополнительные сведения см. в разделе [Развертывание с помощью GitHub Actions](/ru/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#using-environments-without-deployments).\n\n## `jobs..concurrency`\n\nМожно использовать `jobs..concurrency`, чтобы одновременно могли выполняться только одно задание или один процесс с использованием той же группы параллелизма. Группа параллелизма может представлять собой любую строку или выражение. Контексты разрешенных выражений: `github`[](/ru/actions/reference/workflows-and-actions/contexts#github-context),`inputs`[](/ru/actions/reference/workflows-and-actions/contexts#inputs-context) , `vars`[](/ru/actions/reference/workflows-and-actions/contexts#vars-context),`needs`[](/ru/actions/reference/workflows-and-actions/contexts#needs-context) ,`strategy`[](/ru/actions/reference/workflows-and-actions/contexts#strategy-context) и .[`matrix`](/ru/actions/reference/workflows-and-actions/contexts#matrix-context) Дополнительные сведения о выражениях см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\nМожно также указать `concurrency` на уровне рабочего процесса. Дополнительные сведения см. в разделе [`concurrency`](/ru/actions/reference/workflows-and-actions/workflow-syntax#concurrency).\n\nЭто означает, что в группе одновременно может быть максимум одна работающая задача или рабочий процесс. Если параллельное задание или рабочий процесс добавлены в очередь и выполняется другое задание или рабочий процесс, использующие ту же группу параллелизма в репозитории, то находящиеся в очереди задание или рабочий процесс будут `pending`. По умолчанию любая существующая `pending` задача или рабочий процесс в той же группе параллелизма будет отменена, и на её место займёт новая очередная задача или рабочий процесс.\n\nЧтобы также отменить задание или рабочий процесс, которые сейчас выполняются в той же группе параллелизма, укажите `cancel-in-progress: true`. Чтобы условно отменить выполняемые в настоящее время задания или рабочие процессы в той же группе параллелизма, можно указать `cancel-in-progress` как выражение с любым из контекстов разрешенного выражения.\n\nЧтобы позволить `pending` нескольким задачам или рабочим процессам ожидать в одной группе параллелизма, используйте опциональное `queue` свойство. Свойство `queue` принимает следующие значения:\n\n* `single` (по умолчанию): В группе параллелизма может `pending` находиться максимум одна задача или запуск рабочего процесса. Когда новая задача или рабочий процесс ставится в очередь, любая существующая `pending` задача или рабочий процесс, запущенный в той же группе, отменяется и заменяется.\n* `max`: В группе параллелизма может `pending` быть до 100 заданий или запусков рабочих процессов. Когда очередь заполнена, любые дополнительные задания или запуски рабочих процессов отменяются.\n\nКомбинация `queue: max` и `cancel-in-progress: true` не допускается и приведёт к ошибке валидации рабочего процесса.\n\n> \\[!NOTE]\n>\n> * Имя группы параллелизма не учитывает регистр. Например, `prod` и `Prod` будет рассматриваться как та же группа параллелизма.\n> * Задания или рабочие процессы в одной и той же группе параллелизма обрабатываются в порядке «первый вошёл — первый ушёл» (FIFO) в зависимости от времени ожидания группы параллелизма, а не по времени отправки каждого рабочего процесса. Поскольку фактическое время начала работы или запуска может различаться, заказ не гарантируется.\n\n### Пример. Использование параллелизма и поведения по умолчанию\n\nПо умолчанию GitHub Actions режим позволяет выполнять несколько заданий или рабочих процессов одновременно. Ключевое `concurrency` слово позволяет управлять параллелизмом выполнения рабочих процессов.\n\nНапример, ключевое `concurrency` слово можно использовать сразу после определения условий триггера, чтобы ограничить параллелизм всего рабочего процесса для определенной ветви:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nКроме того, можно ограничить параллелизм заданий в рабочем процессе с помощью `concurrency` ключевого слова на уровне задания:\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Пример: группы параллелизма\n\nГруппы параллелизма предоставляют способ управления выполнением и ограничением выполнения выполнения рабочих процессов или заданий, использующих один и тот же ключ параллелизма.\n\nКлюч `concurrency` используется для группировки рабочих процессов или заданий в группу параллелизма. Когда вы определяете ключ `concurrency` , GitHub Actions убедитесь, что в любой момент времени работает только один рабочий процесс или задание с этим ключом. Если новый рабочий процесс или задание начинается с того же `concurrency` ключа, GitHub Actions все рабочие процессы или задания с этим ключом отменяются. Ключ `concurrency` может быть жестко закодированной строкой или может быть динамическим выражением, которое включает в себя переменные контекста.\n\nМожно определить условия параллелизма в рабочем процессе, чтобы рабочий процесс или задание были частью группы параллелизма.\n\nЭто означает, что при запуске или запуске рабочего процесса GitHub отменяет все запуски рабочих процессов или задания, которые уже выполняются в той же группе параллелизма. Это полезно в сценариях, в которых требуется предотвратить параллельные запуски для определенного набора рабочих процессов или заданий, таких как те, которые используются для развертываний в промежуточной среде, чтобы предотвратить действия, которые могут вызвать конфликты или использовать больше ресурсов, чем необходимо.\n\nВ этом примере `job-1` является частью группы параллелизма с именем `staging_environment`. Это означает, что если запускается новый запуск `job-1` , все запуски того же задания в `staging_environment` группе параллелизма, которые уже выполняются, будут отменены.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nКроме того, использование динамического выражения, например `concurrency: ci-${{ github.ref }}` в рабочем процессе, означает, что рабочий процесс или задание будет частью группы `ci-` параллелизма, за которой следует ссылка на ветвь или тег, активировавший рабочий процесс. В этом примере, если новая фиксация отправляется в основную ветвь, пока предыдущий запуск по-прежнему выполняется, предыдущий запуск будет отменен, а новый будет запущен:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Пример: очередь на несколько ожидающих запусков\n\nПо умолчанию в группе параллелизма может `pending` находиться только одна задача или запуск рабочего процесса. Чтобы позволить несколько забегов выстраиваться в очередь вместо отмены, установите `queue: max`. При `queue: max`, до 100 заданий или запусков рабочих процессов могут подождать в группе параллелизма; после заполнения очереди любые дополнительные запуски отменяются.\n\nНапример, следующие рабочие процессы ставят в очередь развертывания в `production` среду, обрабатывая их по одному в порядке в зависимости от того, когда каждый запуск начинал ожидание группы параллелизма:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nОбратите внимание, что `queue: max` нельзя комбинировать с `cancel-in-progress: true`, поскольку оба варианта описывают противоречивые действия при обработке запусков в процессе.\n\n### Пример. Использование параллелизма для отмены любого выполняющегося задания или запуска\n\nЧтобы использовать параллелизм для отмены любой текущей задачи или запускаGitHub Actions, вы можете использовать `concurrency` ключ с опцией`true`:`cancel-in-progress`\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nОбратите внимание, что в этом примере, без определения конкретной группы параллелизма, GitHub Actions\\_будет отменён любой\\_ текущий запуск задания или рабочего процесса.\n\n### Пример. Использование резервного значения\n\nЕсли вы создаете имя группы со свойством, определенным только для определенных событий, можно использовать резервное значение. Например, `github.head_ref` определяется только для событий `pull_request`. Если рабочий процесс реагирует на другие события в дополнение к событиям `pull_request`, необходимо предоставить резервное значение, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или запуски только в событиях `pull_request`. Если параметр `github.head_ref` не определен, группа параллелизма перейдет к идентификатору запуска, который будет гарантированно заданным и уникальным.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий или запусков для текущего рабочего процесса\n\nПри наличии нескольких рабочих процессов в одном репозитории имена групп параллелизма должны быть уникальными в разных рабочих процессах, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае все ранее выполняемые или ожидающие задания будут отменены независимо от рабочего процесса.\n\nЧтобы отменить только выполняемые запуски для одного рабочего процесса, можно использовать свойство `github.workflow` для создания группы параллелизма:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Пример. Отмена только выполняемых заданий в определенных ветвях\n\nЕсли вы хотите отменить выполняемые задания в определенных ветвях, но не на других, можно использовать условные выражения с `cancel-in-progress`. Например, это можно сделать, если вы хотите отменить выполняемые задания в ветвях разработки, но не в ветвях выпуска.\n\nЧтобы отменить выполнение только выполняемых запусков одного рабочего процесса, если он не запущен в ветви выпуска, можно задать `cancel-in-progress` выражение, аналогичное следующему:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nВ этом примере несколько push-уведомлений в `release/1.2.3` ветвь не отменяют выполняемые запуски. Отправка в другую ветвь, например `main`, отменяет выполняемые запуски.\n\n## `jobs..outputs`\n\nМожно использовать `jobs..outputs` для создания `map` выходных данных для задания. Выходные данные задания доступны для всех подчиненных заданий, которые зависят от этого задания. Дополнительные сведения об определении зависимостей заданий см. в разделе [`jobs..needs`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).\n\nВыходные данные могут составлять не более 1 МБ на задание. Общий объем выходных данных в выполнении рабочего процесса не может превышать 50 МБ. Размер приблизительный на основе кодировки UTF-16.\n\nВыходные данные задания, содержащие выражения, вычисляются в средстве выполнения в конце каждого задания. Выходные данные, содержащие секреты, редактируются в средстве выполнения и не отправляются в GitHub Actions.\n\nЕсли выходные данные пропущены, так как он может содержать секрет, появится следующее предупреждение: \"Пропустить выходные данные `{output.Key}` , так как он может содержать секрет\". Дополнительные сведения об обработке секретов см. в [примере: маскирование и передача секрета между заданиями или рабочими процессами](/ru/actions/reference/workflows-and-actions/workflow-commands#example-masking-and-passing-a-secret-between-jobs-or-workflows).\n\nЧтобы применять выходные данные задания в зависимом задании, можно использовать контекст `needs`. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#needs-context).\n\n### Пример: определение выходных данных для задания\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n # Map a step output to a job output\n outputs:\n output1: ${{ steps.step1.outputs.test }}\n output2: ${{ steps.step2.outputs.test }}\n steps:\n - id: step1\n run: echo \"test=hello\" >> \"$GITHUB_OUTPUT\"\n - id: step2\n run: echo \"test=world\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: job1\n steps:\n - env:\n OUTPUT1: ${{needs.job1.outputs.output1}}\n OUTPUT2: ${{needs.job1.outputs.output2}}\n run: echo \"$OUTPUT1 $OUTPUT2\"\n```\n\n### Использование выходных данных задания в матрицном задании\n\nМатрицы можно использовать для создания нескольких выходных данных разных имен. При использовании матрицы выходные данные заданий будут объединены из всех заданий внутри матрицы.\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n outputs:\n output_1: ${{ steps.gen_output.outputs.output_1 }}\n output_2: ${{ steps.gen_output.outputs.output_2 }}\n output_3: ${{ steps.gen_output.outputs.output_3 }}\n strategy:\n matrix:\n version: [1, 2, 3]\n steps:\n - name: Generate output\n id: gen_output\n run: |\n version=\"${{ matrix.version }}\"\n echo \"output_${version}=${version}\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: [job1]\n steps:\n # Will show\n # {\n # \"output_1\": \"1\",\n # \"output_2\": \"2\",\n # \"output_3\": \"3\"\n # }\n - run: echo '${{ toJSON(needs.job1.outputs) }}'\n```\n\n> \\[!WARNING]\n> Действия не гарантируют порядок выполнения заданий матрицы. Убедитесь, что выходное имя уникально, в противном случае последнее задание матрицы, которое выполняется, переопределит выходное значение.\n\n## `jobs..env`\n\nПеременные `map` , доступные для всех шагов в задании. Можно задать переменные для всего рабочего процесса или отдельного шага. Дополнительные сведения см. в разделах [`env`](#env) и [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nПри определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.\n\n### Пример `jobs..env`\n\n```yaml\njobs:\n job1:\n env:\n FIRST_NAME: Mona\n```\n\n## `jobs..defaults`\n\nИспользуйте `jobs..defaults` для создания `map` с параметрами по умолчанию, которые будут применяться ко всем шагам задания. Вы также можете задать параметры по умолчанию для всего рабочего процесса. Дополнительные сведения см. в разделе [`defaults`](/ru/actions/reference/workflows-and-actions/workflow-syntax#defaults).\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `jobs..defaults.run`\n\nИспользует `jobs..defaults.run` для предоставления параметры по умолчанию `shell` и `working-directory` для всех этапов `run` в задании.\n\nМожно указать параметры по умолчанию `shell` и `working-directory` для всех этапов [`run`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) в задании. Вы также можете задать параметры по умолчанию для `run` для всего рабочего процесса. Дополнительные сведения см. в разделе [`defaults.run`](/ru/actions/reference/workflows-and-actions/workflow-syntax#defaultsrun).\n\nИх можно переопределить на `jobs..defaults.run` уровнях и `jobs..steps[*].run` уровнях.\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `jobs..defaults.run.shell`\n\nИспользуется `shell` для определения `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#context-availability)\".\n\n| Поддерживаемая платформа | `shell` параметр | Description | Выполнение команды внутри системы |\n| ------------------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- |\n| Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать `bash` явно. Если `bash` не удается найти в пути, выполняется обработка в качестве `sh`. | `bash -e {0}` |\n| Все | `bash` | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом `sh`. При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Все | `pwsh` | PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. | `pwsh -command \". '{0}'\"` |\n| Все | `python` | Выполняет команду Python. | `python {0}` |\n| Linux / macOS | `sh` | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и `bash` не найден в пути. | `sh -e {0}` |\n| Windows | `cmd` | GitHub добавляет расширение `.cmd` к имени скрипта и заменяет `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. Если в локальном средстве выполнения Windows не установлен *PowerShell Core*, будет использоваться *PowerShell Desktop*. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub добавляет расширение `.ps1` к имени скрипта. | `powershell -command \". '{0}'\"`. |\n\nЕсли определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n## `jobs..defaults.run.working-directory`\n\nИспользуется `working-directory` для определения рабочего каталога для `shell` шага. Это ключевое слово может ссылаться на несколько контекстов. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#context-availability)\".\n\n> \\[!TIP]\n> Перед запуском оболочки убедитесь, что `working-directory` назначаемая функция существует в средстве выполнения.\n> Если определено несколько параметров по умолчанию с одинаковым именем, GitHub использует наиболее конкретный из них. Например, параметр по умолчанию, указанный в задании, переопределит параметр по умолчанию с тем же именем, указанным в рабочем процессе.\n\n### Пример. Настройка параметров этапа по умолчанию `run` для задания\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n defaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `jobs..steps`\n\nЗадание содержит последовательность задач, называемых шагами (`steps`). Шаги могут выполнять команды, задачи установки или действия в репозитории, общедоступном репозитории или в реестре Docker. Не все шаги выполняют действия, но все действия выполняются как шаги. Каждый шаг выполняется в собственном процессе в среде средства выполнения и имеет доступ к рабочей области и файловой системе. Так как шаги выполняются в собственном процессе, изменения переменных среды не сохраняются между шагами.\nGitHub предоставляет встроенные шаги для организации и завершения работы.\n\nGitHub Отображается только первые 1000 проверок, однако вы можете выполнять неограниченное количество шагов, если находитесь в пределах лимитов использования рабочего процесса. Для получения дополнительной информации см. [Выставление счетов и использование](/ru/actions/concepts/billing-and-usage) для GitHub-hosted runners и [Ограничения действий](/ru/actions/reference/limits) для самостоятельных ограничений использования бегунов.\n\n### Пример `jobs..steps`\n\n```yaml\nname: Greeting from Mona\n\non: push\n\njobs:\n my-job:\n name: My Job\n runs-on: ubuntu-latest\n steps:\n - name: Print a greeting\n env:\n MY_VAR: Hi there! My name is\n FIRST_NAME: Mona\n MIDDLE_NAME: The\n LAST_NAME: Octocat\n run: |\n echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.\n```\n\n## `jobs..steps[*].id`\n\nУникальный идентификатор шага. Вы можете использовать `id` для ссылки на шаг в контекстах. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts).\n\n## `jobs..steps[*].if`\n\nУсловное выражение `if` можно использовать для предотвращения выполнения шага, если условие не выполняется. Для создания условного выражения можно использовать любой поддерживаемый контекст и любое выражение. Дополнительные сведения о том, какие контексты поддерживаются в этом ключе, см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#context-availability).\n\nПри использовании выражений в условном `if` режиме можно, при необходимости, опустить синтаксис выражения `${{ }}`, так как GitHub Actions автоматически вычисляет условное `if` выражение как выражение. Однако это исключение не применяется везде.\n\nВсегда следует использовать синтаксис выражения `${{ }}`концевого выражения %} или экранировать с `''`, `\"\"`либо `()` когда выражение начинается с `!`, так как `!` зарезервировано нотация в формате YAML. Например:\n\n{% raw %}\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nДля получения дополнительной информации см. [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\n### Пример. Использование контекстов\n\nЭтот шаг выполняется, только если типом события является `pull_request`, а действием — `unassigned`.\n\n```yaml\nsteps:\n - name: My first step\n if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n run: echo This event is a pull request that had an assignee removed.\n```\n\n### Пример. Использование функций проверки состояния\n\n`my backup step` выполняется только при сбое предыдущего шага задания. Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions#status-check-functions).\n\n```yaml\nsteps:\n - name: My first step\n uses: octo-org/action-name@main\n - name: My backup step\n if: ${{ failure() }}\n uses: actions/heroku@1.0.0\n```\n\n### Пример. Использование секретов\n\nНа секреты нельзя напрямую ссылаться в условных выражениях `if:`. Вместо этого рекомендуется задать секреты в качестве переменных среды на уровне задания, а затем создать ссылки на переменные среды для условного выполнения шагов в задании.\n\nЕсли секрет не установлен, возвращаемое значение выражения, ссылающегося на секрет (например `${{ secrets.SuperSecret }}` , в примере), будет пустой строкой.\n\n```yaml\nname: Run a step if a secret has been set\non: push\njobs:\n my-jobname:\n runs-on: ubuntu-latest\n env:\n super_secret: ${{ secrets.SuperSecret }}\n steps:\n - if: ${{ env.super_secret != '' }}\n run: echo 'This step will only run if the secret has a value set.'\n - if: ${{ env.super_secret == '' }}\n run: echo 'This step will only run if the secret does not have a value set.'\n```\n\nДополнительные сведения см. в разделе \\[AUTOTITLE и [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#context-availability)]\\(/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\n## `jobs..steps[*].name`\n\nНазвание для вашего шага для отображения на GitHub.\n\n## `jobs..steps[*].uses`\n\nВыбирает действие, которое будет выполняться как часть шага вашего задания. Действие — это многократно используемая единица кода. Вы можете использовать действие, определенное в том же репозитории, что и рабочий процесс, в общедоступном репозитории или в [опубликованном образе контейнера Docker](https://hub.docker.com/).\n\nМы настоятельно рекомендуем включить версию используемого вами действия, указав ссылку на Git, SHA или тег Docker. Если вы не укажете версию, это может нарушить ваши рабочие процессы или вызвать непредвиденное поведение, когда владелец действия будет публиковать обновление.\n\n* Использование SHA фиксации выпущенной версии действия является самым безопасным для стабильности и защиты.\n* Если действие публикует теги основного номера версий, вам следует ожидать получения критических исправлений и обновлений для системы безопасности. При этом совместимость сохранится. Обратите внимание, что это поведение выполняется по усмотрению автора действия.\n* Использование ветви действия по умолчанию может быть удобным, но если кто-то выпустит новую основную версию с критическим изменением, ваш рабочий процесс может прерваться.\n\nДля некоторых действий требуются входные данные, заданные с помощью ключевого слова [`with`](#jobsjob_idstepswith). Просмотрите файл README действия, чтобы определить необходимые ввода.\n\nДействия — это файлы JavaScript или контейнеры Docker. Если используемое действие является контейнером Docker, необходимо запустить задание в среде Linux. Дополнительные сведения см. в статье [`runs-on`](#jobsjob_idruns-on).\n\n### Пример. Использование действий с версиями\n\n```yaml\nsteps:\n # Reference a specific commit\n - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n # Reference the major version of a release\n - uses: actions/checkout@v6\n # Reference a specific version\n - uses: actions/checkout@v6.2.0\n # Reference a branch\n - uses: actions/checkout@main\n```\n\n### Пример. Использование общедоступного действия\n\n`{owner}/{repo}@{ref}`\n\nВы можете указать ветку, ссылку или SHA в публичном GitHub репозитории.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n # Uses the default branch of a public repository\n uses: actions/heroku@main\n - name: My second step\n # Uses a specific version tag of a public repository\n uses: actions/aws@v2.0.1\n```\n\n### Пример. Использование общедоступного действия в подкаталоге\n\n`{owner}/{repo}/{path}@{ref}`\n\nПодкаталог в публичном GitHub репозитории в конкретном филиале, ссылке или SHA.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/aws/ec2@main\n```\n\n### Пример. Использование действия в том же репозитории, что и рабочий процесс при выполнении фиксации (рекомендуется)\n\n`$/path/to/action`\n\nПрефикс `$/` — это ссылка на самостоятельный репозиторий. Он ссылается на действие, хранящееся в том же репозитории, что и рабочий процесс или действие, которое в настоящее время выполняется, и разрешает это репозиторий при выполнении фиксации (то же SHA, что и выполняющийся рабочий процесс или действие). Сначала не нужно извлечь репозиторий, поэтому рекомендуется ссылаться на действие в собственном репозитории.\n\nСинтаксис `$/` недоступен в GitHub Enterprise Server.\n\nСсылка `$/` не должна включать `@{ref}` суффикс. Ссылка всегда является фиксацией выполняемого рабочего процесса или действия, поэтому ссылка, например `$/actions/my-action@v1` недопустимая.\n\n`$/` всегда разрешает репозиторий файла, в который он отображается, а не репозиторий, который его назвал. Например, если повторно используемый рабочий процесс в одном репозитории вызывается рабочим процессом в другом репозитории, `$/` ссылка в вызываемом рабочем процессе разрешается в репозиторий вызываемого рабочего процесса, а не в репозитории вызывающего рабочего процесса. Это делает `$/` надежным для композиции действий, где относительный `./` путь вместо этого будет разрешать против того, что извлечено в рабочей области вызывающего объекта. Сведения об использовании `$/` в шагах составного действия см. в разделе [Справочник по синтаксису метаданных](/ru/actions/reference/workflows-and-actions/metadata-syntax#runsstepsuses).\n\nВ следующей таблице сравниваются способы ссылки на действие.\n\n| Syntax | Разрешение на | Рекомендуется для |\n| ---------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------- |\n| `$/path/to/action` | Тот же репозиторий, что и запущенный рабочий процесс или действие, при выполнении фиксации | Действия в одном репозитории |\n| `{owner}/{repo}@{ref}` | Указанный репозиторий по указанному ссылке | Действия в другом репозитории |\n| `./path/to/action` | Путь к извлеченной рабочей области runner относительно рабочего каталога по умолчанию (`${{ github.workspace }}`) | Только пограничные случаи |\n\n```yaml\non: [push]\n\njobs:\n my_first_job:\n runs-on: ubuntu-latest\n steps:\n # References an action in the same repository at the running commit\n - uses: $/.github/actions/hello-world-action\n```\n\n### Пример. Использование действия в том же репозитории, что и рабочий процесс\n\n`./path/to/dir`\n\nПуть к каталогу, содержащему действие в репозитории рабочего процесса. Перед использованием действия необходимо извлечь репозиторий, а `./` путь разрешается в рабочей области runner, а не в репозитории выполняемого рабочего процесса. В большинстве случаев используйте приведенный `$/` выше синтаксис.\n\nПример структуры файла репозитория:\n\n```shell\n|-- hello-world (repository)\n| |__ .github\n| └── workflows\n| └── my-first-workflow.yml\n| └── actions\n| |__ hello-world-action\n| └── action.yml\n```\n\nПуть является относительным (`./`) к рабочему каталогу по умолчанию (`github.workspace`, `$GITHUB_WORKSPACE`). Если действие извлекает репозиторий в расположение, отличное от рабочего процесса, необходимо обновить относительный путь, используемый для локальных действий.\n\nПример файла рабочего процесса:\n\n```yaml\njobs:\n my_first_job:\n runs-on: ubuntu-latest\n steps:\n # This step checks out a copy of your repository.\n - name: My first step - check out repository\n uses: actions/checkout@v6\n # This step references the directory that contains the action.\n - name: Use local hello-world-action\n uses: ./.github/actions/hello-world-action\n```\n\n### Пример. Использование действия Docker Hub\n\n`docker://{image}:{tag}`\n\nОбраз Docker, опубликованный в [Docker Hub](https://hub.docker.com/).\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://alpine:3.8\n```\n\n### Пример: Использование GitHub PackagesContainer registry\n\n`docker://{host}/{image}:{tag}`\n\nПубличное изображение Docker в GitHub PackagesContainer registry.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://ghcr.io/OWNER/IMAGE_NAME\n```\n\n### Пример. Использование действия общедоступного реестра Docker\n\n`docker://{host}/{image}:{tag}`\n\nОбраз Docker в общедоступном реестре. В этом примере используется реестр контейнеров Google: `gcr.io`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://gcr.io/cloud-builders/gradle\n```\n\n### Пример. Использование действия в частном репозитории, отличном от того, где выполняется рабочий процесс\n\nЕсли действие находится во внутреннем репозитории или в приватном репозитории, настроенном для доступа из репозитория вашего рабочего процесса, вы можете напрямую обратиться к этому действию. Дополнительные сведения см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository) и [](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).\n\nЕсли действие не находится в репозитории, настроенном для доступа, нужно проверить репозиторий и ссылаться на действие локально. Сгенерируйте a personal access token и добавьте токен как секрет. Следующий пример демонстрирует этот способ ссылки на действие. Дополнительные сведения см. в разделе \\[AUTOTITLE и [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)]\\(/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nЗамените `PERSONAL_ACCESS_TOKEN` в примере именем секрета.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: Check out repository\n uses: actions/checkout@v6\n with:\n repository: octocat/my-private-repo\n ref: v1.0\n token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n path: ./.github/actions/my-private-repo\n - name: Run my action\n uses: ./.github/actions/my-private-repo/my-action\n```\n\nВ качестве альтернативы используйте a GitHub App вместо a personal access token , чтобы ваш рабочий процесс продолжался даже если personal access token владелец уходит. Дополнительные сведения см. в разделе [Создание аутентифицированных запросов API с помощью приложения GitHub в рабочем процессе GitHub Actions](/ru/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).\n\n## `jobs..steps[*].run`\n\nЗапускает программы командной строки, не превышающие 21 000 символов с помощью оболочки операционной системы. Если `name` не указано, в качестве имени шага по умолчанию используется текст, указанный в команде `run`.\n\nКоманды выполняются с помощью оболочки, не требующей входа, по умолчанию. Вы можете выбрать другую оболочку и настроить ее для выполнения команд. Дополнительные сведения см. в разделе [`jobs..steps[*].shell`](#jobsjob_idstepsshell).\n\nКаждое ключевое слово `run` представляет новый процесс и оболочку в среде средства выполнения. При предоставлении команд с несколькими строками каждая строка выполняется в той же оболочке. Например:\n\n* Команда с одной строкой:\n\n ```yaml\n - name: Install Dependencies\n run: npm install\n ```\n\n* Команда с несколькими строками:\n\n ```yaml\n - name: Clean install dependencies and build\n run: |\n npm ci\n npm run build\n ```\n\n## `jobs..steps[*].working-directory`\n\nС помощью ключевого слова `working-directory` можно указать рабочий каталог, в котором будет выполняться команда.\n\n```yaml\n- name: Clean temp directory\n run: rm -rf *\n working-directory: ./temp\n```\n\nКроме того, можно указать рабочий каталог по умолчанию для всех `run` шагов в задании или для всех `run` шагов всего рабочего процесса. Дополнительные сведения см. в разделах [`defaults.run.working-directory`](/ru/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunworking-directory) и [`jobs..defaults.run.working-directory`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunworking-directory).\n\nВы также можете использовать `run` шаг для запуска скрипта. Дополнительные сведения см. в разделе [Добавление сценариев в рабочий процесс](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/add-scripts).\n\n## `jobs..steps[*].shell`\n\nПараметры оболочки по умолчанию можно переопределить в операционной системе runner и по умолчанию задания с помощью ключевого `shell` слова. Можно использовать встроенные ключевые слова `shell` или определить пользовательский набор параметров оболочки. Команда оболочки, выполняемая внутри системы, исполняет временный файл, содержащий команды, указанные в ключевом слове `run`.\n\n| Поддерживаемая платформа | `shell` параметр | Description | Выполнение команды внутри системы |\n| ------------------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- |\n| Linux / macOS | unspecified | Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем когда указать `bash` явно. Если `bash` не удается найти в пути, выполняется обработка в качестве `sh`. | `bash -e {0}` |\n| Все | `bash` | Оболочка по умолчанию на платформах, отличных от Windows, с резервным вариантом `sh`. При указании оболочки Bash на Windows используется оболочка Bash, включенная в Git для Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Все | `pwsh` | PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. | `pwsh -command \". '{0}'\"` |\n| Все | `python` | Выполняет команду Python. | `python {0}` |\n| Linux / macOS | `sh` | Резервное поведение для платформ, отличных от Windows, если оболочка не указана и `bash` не найден в пути. | `sh -e {0}` |\n| Windows | `cmd` | GitHub добавляет расширение `.cmd` к имени скрипта и заменяет `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Это оболочка по умолчанию, используемая в Windows. PowerShell Core. GitHub добавляет расширение `.ps1` к имени скрипта. Если в локальном средстве выполнения Windows не установлен *PowerShell Core*, будет использоваться *PowerShell Desktop*. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub добавляет расширение `.ps1` к имени скрипта. | `powershell -command \". '{0}'\"`. |\n\nКроме того, можно указать оболочку по умолчанию для всех `run` шагов в задании или для всех `run` шагов всего рабочего процесса. Дополнительные сведения см. в разделах [`defaults.run.shell`](/ru/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunshell) и [`jobs..defaults.run.shell`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunshell).\n\n### Пример. Выполнение команды с помощью Bash\n\n```yaml\nsteps:\n - name: Display the path\n shell: bash\n run: echo $PATH\n```\n\n### Пример. Выполнение команды с помощью Windows `cmd`\n\n```yaml\nsteps:\n - name: Display the path\n shell: cmd\n run: echo %PATH%\n```\n\n### Пример. Выполнение команды с помощью PowerShell Core\n\n```yaml\nsteps:\n - name: Display the path\n shell: pwsh\n run: echo ${env:PATH}\n```\n\n### Пример. Использование PowerShell Desktop для выполнения команды\n\n```yaml\nsteps:\n - name: Display the path\n shell: powershell\n run: echo ${env:PATH}\n```\n\n### Пример. Выполнение встроенного скрипта Python\n\n```yaml\nsteps:\n - name: Display the path\n shell: python\n run: |\n import os\n print(os.environ['PATH'])\n```\n\n### Пользовательская оболочка\n\nВы можете задать для значения `shell` строку шаблона с помощью `command [options] {0} [more_options]`.\nGitHub интерпретирует первое слово строки, разделённое пробелами, как команду и вставляет имя файла временного скрипта в `{0}`.\n\nНапример:\n\n```yaml\nsteps:\n - name: Display the environment variables and their values\n shell: perl {0}\n run: |\n print %ENV\n```\n\nИспользуемая команда, в этом примере `perl`, должна быть установлена в средстве выполнения.\n\nДля получения информации о программном обеспечении, включённом в раннеры на GitHub, см. [Средства выполнения тестов, размещенные в GitHub](/ru/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images).\n\n### Коды выхода и настройки действий в случае ошибок\n\nДля встроенных shell-ключевых слов мы предоставляем следующие параметры по умолчанию, которые выполняются GitHub-hosted runners. Эти рекомендации следует использовать при выполнении скриптов оболочки.\n\n* `bash`\n /\n `sh`:\n * По умолчанию для обоих и `set -e`для обоих `sh` используется принудительное поведение сбоем`bash`. При `shell: bash` указании `-o pipefail` также применяется для принудительного раннего выхода из конвейеров, которые создают состояние выхода, отличного от нуля.\n * Вы можете получить полный контроль над параметрами оболочки, указав строку шаблона для параметров оболочки. Например, `bash {0}`.\n * `sh`-например, оболочки выходят с кодом выхода последней команды, выполняемой в скрипте, которая также является поведением по умолчанию для действий. Средство выполнения сообщит о состоянии шага (сбой/успешно) в зависимости от этого кода выхода.\n\n* `powershell`/`pwsh`\n * Используйте завершение работы при первой ошибке по возможности. Для `pwsh` и встроенной оболочки `powershell` мы добавим `$ErrorActionPreference = 'stop'` к содержимому скрипта.\n * Мы добавляем `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` к скриптам PowerShell, чтобы состояния действий отражали последний код выхода скрипта.\n * Пользователи всегда могут отказаться от использования встроенной оболочки и предоставить настраиваемый параметр оболочки, например: `pwsh -File {0}` или `powershell -Command \"& '{0}'\"`, в зависимости от необходимости.\n\n* `cmd`\n * Кажется, что единственный способ настроить завершение работы при первой ошибке, — написать скрипт для проверки каждого кода ошибки и соответствующего реагирования. Так как мы не можем предоставить это поведение по умолчанию, необходимо записать это поведение в скрипт.\n * `cmd.exe` завершит работу с уровнем ошибки последней выполняемой программы и вернет код ошибки средству выполнения. Это поведение внутренне согласуется с предыдущим поведением по умолчанию `sh` и `pwsh` и является `cmd.exe` по умолчанию, поэтому это поведение остается неизменным.\n\n## `jobs..steps[*].with`\n\n`map` параметров ввода, определяемых действием. Каждый параметр ввода представляет собой пару \"ключ-значение\". Параметры ввода задаются как переменные среды. Переменная имеет префикс `INPUT_` и преобразуется в верхний регистр.\n\nВходные параметры, определенные для контейнера Docker, должны использоваться `args`. Дополнительные сведения см. в разделе [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs).\n\n### Пример `jobs..steps[*].with`\n\nОпределяет три входных параметра (`first_name`, `middle_name` и `last_name`), определенные действием `hello_world`. Эти входные переменные будут доступны для действия `hello-world` как переменные среды `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` и `INPUT_LAST_NAME`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/hello_world@main\n with:\n first_name: Mona\n middle_name: The\n last_name: Octocat\n```\n\n## `jobs..steps[*].with.args`\n\nСтрока `string`, определяющая входные данные для контейнера Docker.\nGitHub передаёт `args``ENTRYPOINT` контейнеры контейнерам, когда контейнер запускается.\n`array of strings` не поддерживается этим параметром. Один аргумент, содержащий пробелы, должен быть окружен двойными кавычками `\"\"`.\n\n### Пример `jobs..steps[*].with.args`\n\n```yaml\nsteps:\n - name: Explain why this job ran\n uses: octo-org/action-name@main\n with:\n entrypoint: /bin/echo\n args: The ${{ github.event_name }} event triggered this step.\n```\n\n`args` используются вместо инструкции `CMD` в `Dockerfile`. Если вы используете `CMD` в `Dockerfile`, следуйте этим рекомендациям, упорядоченным по предпочтительности:\n\n1. Задокументируйте обязательные аргументы в README действия и опустите их из инструкции `CMD`.\n2. Используйте значения по умолчанию, позволяющие использовать действие без указания `args`.\n3. Если действие предоставляет флаг `--help` или что-то подобное, используйте его по умолчанию, чтобы действие документировало само себя.\n\n## `jobs..steps[*].with.entrypoint`\n\nПереопределяет параметр `ENTRYPOINT` Docker в `Dockerfile` или задает его, если он еще не был указан. В отличие от инструкции Docker `ENTRYPOINT`, которая имеет форму оболочки и выполнения, ключевое слово `entrypoint` принимает только одну строку, определяющую исполняемый файл для запуска.\n\n### Пример `jobs..steps[*].with.entrypoint`\n\n```yaml\nsteps:\n - name: Run a custom command\n uses: octo-org/action-name@main\n with:\n entrypoint: /a/different/executable\n```\n\nКлючевое слово `entrypoint` предназначено для использования с действиями контейнера Docker, но его также можно использовать с действиями JavaScript, которые не определяют входные данные.\n\n## `jobs..steps[*].env`\n\nЗадает переменные для шагов, используемых в среде запуска. Можно также задать переменные для всего рабочего процесса или задания. Дополнительные сведения см. в разделах [`env`](#env) и [`jobs..env`](#jobsjob_idenv).\n\nПри определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется.\n\nОбщедоступные действия могут указывать ожидаемые переменные в файле README. Если вы задаете секретное или конфиденциальное значение, например пароль или маркер, необходимо задать секреты с помощью контекста `secrets` . Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts).\n\n### Пример `jobs..steps[*].env`\n\n```yaml\nsteps:\n - name: My first action\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n FIRST_NAME: Mona\n LAST_NAME: Octocat\n```\n\n## `jobs..steps[*].continue-on-error`\n\nПредотвращает сбой задания при сбое шага. Задайте значение `true`, чтобы задание считалось выполненным при сбое этого шага.\n\n## `jobs..steps[*].timeout-minutes`\n\nМаксимальное количество минут для выполнения шага перед завершением процесса. Максимум: 360 как GitHubдля ведущих, так и для самостоятельных бегунов.\n\nДробные значения не поддерживаются.\n`timeout-minutes` должно быть положительным целым числом.\n\n## `jobs..steps[*].background`\n\nОн идёт на шаг асинхронно, чтобы работа продолжалась на следующий этап без ожидания завершения. Используйте `background: true` для долгосрочных процессов, таких как базы данных, серверы или задачи мониторинга, которые должны выполняться параллельно с другими этапами. Вы синхронизируете с фоновыми шагами позже, используя [`wait`](#jobsjob_idstepswait) или [`wait-all`](#jobsjob_idstepswait-all) , или останавливаете их с [`cancel`](#jobsjob_idstepscancel)помощью .\n\nВы можете использовать `background` на шагах, которые используют `run` или `uses`. Чтобы ссылаться на фоновый шаг из [`wait`](#jobsjob_idstepswait) или [`cancel`](#jobsjob_idstepscancel), поставьте ему .[`id`](#jobsjob_idstepsid) Максимум 10 этапов фона могут выполняться одновременно в одной задаче; Дополнительные этапы фона ставятся в очередь, пока слот не освободится.\n\nВыводы и изменения среды с фонового шага доступны только после выполнения `wait` шага или `wait-all` с этим шагом. Если фоновый шаг провалился, задание проваливается на следующем `wait` или `wait-all` это включает его (если [`continue-on-error`](#jobsjob_idstepscontinue-on-error) только не установлено именно на этом этапе). Неявное `wait-all` действие происходит до любой уборки после работы.\n\nИспользуйте `background` то, когда нужен тонкий контроль: запуск длительного процесса (например, сервера или базы данных), который остаётся активным, пока идут последующие шаги, ссылка на конкретный шаг с [`wait`](#jobsjob_idstepswait) или [`cancel`](#jobsjob_idstepscancel)или перемежание фоновой работы с другими шагами. Если у вас есть самостоятельная группа шагов, которые должны завершиться до начала работы, [`parallel`](#jobsjob_idstepsparallel) это более удобное сокращение.\n\n> \\[!NOTE]\n> Вы не можете использовать `background` шаги внутри композитного действия. Композитное действие может выполняться как фоновый шаг, но не может внутренне объявлять фоновые шаги.\n\n### Пример: Бег шага в фоне\n\n```yaml\nsteps:\n - name: Start server\n id: server\n run: npm start\n background: true\n\n - name: Run tests against the server\n run: npm test\n\n - name: Wait for the server step to finish\n wait: server\n```\n\n## `jobs..steps[*].wait`\n\nСтавит работу на паузу до завершения одного или нескольких этапов фона. Сам шаг `wait` не выполняет работу, он блокирует только до завершения указанных фоновых шагов. Предоставьте один шаг `id` в виде строки или несколько шагов `id`s в виде массива.\n\nПосле завершения шага `wait` выходы указанных фоновых шагов становятся доступны для последующих шагов. Если упомянутый фоновый шаг провалился, он `wait` тоже провалился.\n\n> \\[!NOTE]\n> Шаг `wait` всегда выполняется и не поддерживает условный [`if`](#jobsjob_idstepsif) вариант.\n\n### Пример: Ожидание конкретных этапов предыстории\n\n```yaml\nsteps:\n - name: Build frontend\n id: build-frontend\n run: npm run build:frontend\n background: true\n\n - name: Build backend\n id: build-backend\n run: npm run build:backend\n background: true\n\n - name: Run linter while builds run\n run: npm run lint\n\n - name: Wait for both builds to finish\n wait: [build-frontend, build-backend]\n\n - name: Run tests\n run: npm test\n```\n\n## `jobs..steps[*].wait-all`\n\nСтавит задачу на паузу до завершения всех активных фоновых шагов. Это полезно, когда выполняется несколько фоновых шагов, и вы хотите, чтобы все они были завершены до продолжения. Например, `wait` шаг проваливается, если какой-либо из фоновых шагов, на которых `wait-all`он ожидает, не провалился, если только вы не установили .`continue-on-error`[](#jobsjob_idstepscontinue-on-error)\n\nКлючевое `wait-all` слово не требует споров.\n\n> \\[!NOTE]\n> Шаг `wait-all` всегда выполняется и не поддерживает условный [`if`](#jobsjob_idstepsif) вариант.\n\n### Пример: ожидание всех этапов фона\n\n```yaml\nsteps:\n - name: Start database\n id: db\n run: docker run -d postgres:15\n background: true\n\n - name: Start cache\n id: cache\n run: docker run -d redis:7\n background: true\n\n - name: Run integration tests\n run: npm run test:integration\n\n - name: Wait for all services to stop\n wait-all:\n```\n\n## `jobs..steps[*].cancel`\n\nГрациозно завершает бегущий фоновый шаг. Бегущий отправляет процессу этапа сигнал завершения (`SIGTERM`), чтобы он мог очистить, и насильно останавливает его (`SIGKILL`), если он не выйдет в течение короткого льготного периода. Ключевое слово нацелено `cancel` на один шаг фона по своему `id`.\n\n> \\[!NOTE]\n> Шаг `cancel` всегда выполняется и не поддерживает условный [`if`](#jobsjob_idstepsif) вариант.\n\n### Пример: отмена фонового шага\n\n```yaml\nsteps:\n - name: Start long-running monitor\n id: monitor\n run: ./scripts/monitor.sh\n background: true\n\n - name: Run the main task\n run: npm test\n\n - name: Stop the monitor\n cancel: monitor\n```\n\n## `jobs..steps[*].parallel`\n\nВыполняет группу шагов одновременно, затем ждёт, пока все закончат, прежде чем продолжить. Ключевое слово — сокращение `parallel` : каждый шаг в группе проходит как фоновый шаг, с неявным `wait` в конце группы. Используйте его, когда у вас есть независимая группа шагов, которые могут выполняться одновременно, и вам не нужно сверять их по отдельности.\n\nИспользуйте `parallel` его, когда у вас есть отдельная группа шагов, которые должны завершиться до завершения работы, например, создание нескольких компонентов одновременно. Используйте [`background`](#jobsjob_idstepsbackground) то, когда нужен более тонкий контроль: запуск долгосрочного процесса (например, сервера или базы данных), который остаётся активным, пока идут последующие шаги, ссылка на конкретный шаг с [`wait`](#jobsjob_idstepswait) или [`cancel`](#jobsjob_idstepscancel)или перемежание фоновой работы с другими шагами. Короче говоря, `parallel` это более ограниченно, но удобнее для случая «запустить эту группу сразу», тогда `background` как является универсальным примитивом.\n\nКаждый шаг в группе подчиняется тому же ограничению в 10 шагов параллелизма, что и другие фоновые этапы.\n\n> \\[!NOTE]\n> Вы не можете использовать `parallel` его внутри композитного механизма.\n\n### Пример: Параллельный бег шагов\n\n```yaml\nsteps:\n - uses: actions/checkout@v6\n\n - parallel:\n - name: Build frontend\n run: npm run build:frontend\n\n - name: Build backend\n run: npm run build:backend\n\n - name: Build docs\n run: npm run build:docs\n\n - name: Run tests after all builds complete\n run: npm test\n```\n\nПриведённая выше группа эквивалентна объявлению каждого шага с `background: true` последующим `wait` шагом.\n\n## `jobs..timeout-minutes`\n\nМаксимальное количество минут для запуска задания GitHub автоматически отменяет её. Значение по умолчанию: 360\n\nЕсли время ожидания превышает ограничение по времени выполнения задания для средства выполнения, задание будет отменено, когда будет достигнуто ограничение времени выполнения. Для получения дополнительной информации о сроках выполнения заданий см. [Выставление счетов и использование](/ru/actions/concepts/billing-and-usage#usage-limits-and-policy) для GitHub-hosted runners и [Ограничения действий](/ru/actions/reference/limits) для лимитов использования самостоятельных пользователей.\n\n> \\[!NOTE]\n> Срок действия `GITHUB_TOKEN` истекает при завершении задания или в течение не более 24 часов. Для самостоятельных пользователей токен может быть ограничивающим фактором, если тайм-аут превышает 24 часа. Дополнительные сведения об этом `GITHUB_TOKEN`см. в разделе [Использование GITHUB\\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/tutorials/authenticate-with-github_token).\n\n## `jobs..strategy`\n\nИспользуйте `jobs..strategy` для применения стратегии матрицы к заданиям.\nСтратегия матрицы позволяет использовать переменные в одном определении задания для автоматического создания нескольких выполнений заданий, основанных на сочетаниях переменных. Например, можно использовать стратегию матрицы для тестирования кода в нескольких версиях языка или в нескольких операционных системах. Для получения дополнительной информации см. [Выполнение вариантов заданий в рабочем процессе](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\n## `jobs..strategy.matrix`\n\nИспользуйте `jobs..strategy.matrix` для создания матрицы различных конфигураций заданий Дополнительные сведения см. в разделе [Выполнение вариантов заданий в рабочем процессе](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\nМатрица создаст не более 256 заданий для каждого выполнения рабочего процесса. Это ограничение распространяется как GitHubна -hosting, так и на самостоятельных бегунов.\n\nПеременные, которые вы определяете, становятся свойствами в контексте `matrix`, и можно ссылаться на это свойство в других областях файла рабочего процесса. В этом примере можно использовать `matrix.version` и `matrix.os`, чтобы получить доступ к текущим значениям `version` и `os`, которые использует задание. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts).\n\nПо умолчанию GitHub максимальное количество параллельных заданий в зависимости от доступности раннера. Порядок переменных в матрице определяет порядок создания заданий. Первая переменная, которую вы определите, будет первым заданием, созданным в ходе выполнения рабочего процесса.\n\n### Использование матрицы с одним измерением\n\nСледующий рабочий процесс определяет переменную `version` со значениями `[10, 12, 14]`. Рабочий процесс будет выполнять три задания, по одному для каждого значения в переменной. Каждое задание будет получать доступ к значению `version` через контекст `matrix.version` и передавать значение `node-version` в действие `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n version: [10, 12, 14]\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.version }}\n```\n\n### Использование многомерной матрицы\n\nУкажите несколько переменных для создания многомерной матрицы. Задание будет выполняться для каждой возможной комбинации переменных.\n\nНапример, для следующего рабочего процесса устанавливаются две переменные:\n\n* Две операционные системы, указанные в переменной `os`\n* Три версии Node.js, указанные в переменной `version`\n\nРабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных `os` и `version`. В каждом задании параметру `runs-on` присваивается текущее значение `os` и передается текущее значение `version` в действие `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [ubuntu-22.04, ubuntu-24.04]\n version: [10, 12, 14]\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.version }}\n```\n\nКонфигурация переменной в матрице может иметь значение `array``object`s. Например, следующая матрица создает 4 задания с соответствующими контекстами.\n\n```yaml\nmatrix:\n os:\n - ubuntu-latest\n - macos-latest\n node:\n - version: 14\n - version: 20\n env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\nКаждое задание в матрице будет иметь собственное сочетание `os` и `node` значения, как показано ниже.\n\n```yaml\n- matrix.os: ubuntu-latest\n matrix.node.version: 14\n- matrix.os: ubuntu-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n- matrix.os: macos-latest\n matrix.node.version: 14\n- matrix.os: macos-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n## `jobs..strategy.matrix.include`\n\nДля каждого объекта в списке `include` пары ключ:значение в объекте будут добавлены к каждой из комбинаций матриц, если ни одна из пар ключ:значение не перезаписывает какие-либо исходные значения матрицы. Если объект не может быть добавлен в какие-либо комбинации матриц, будет создана новая. Обратите внимание, что исходные матричные значения не будут перезаписаны, но добавленные матричные значения могут быть перезаписаны.\n\n### Пример. Развертывание конфигураций\n\nНапример, следующий рабочий процесс будет выполнять четыре задания, по одному для каждого сочетания `os` и `node`. Если выполняется задание для значения `windows-latest` параметра `os` и значения `16` параметра `node`, в задание будет включена дополнительная переменная `npm` со значением `6`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [windows-latest, ubuntu-latest]\n node: [14, 16]\n include:\n - os: windows-latest\n node: 16\n npm: 6\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.node }}\n - if: ${{ matrix.npm }}\n run: npm install -g npm@${{ matrix.npm }}\n - run: npm --version\n```\n\n### Пример. Добавление конфигураций\n\nНапример, в этой матрице будет выполняться 10 заданий, по одному для каждого сочетания `os` и `version` в матрице, а также еще одно задание для `windows-latest` со значением `os` и `17` со значением `version`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [macos-latest, windows-latest, ubuntu-latest]\n version: [12, 14, 16]\n include:\n - os: windows-latest\n version: 17\n```\n\nЕсли не указать переменные матрицы, будут выполняться все конфигурации в `include`. Например, следующий рабочий процесс выполнит два задания, по одному для каждого элемента `include`. Это позволяет использовать не полностью заполненную матрицу.\n\n```yaml\njobs:\n includes_only:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n include:\n - site: \"production\"\n datacenter: \"site-a\"\n - site: \"staging\"\n datacenter: \"site-b\"\n```\n\n## `jobs..strategy.matrix.exclude`\n\nИсключенная конфигурация должна иметь хотя бы частичное совпадение, чтобы ее можно было исключить.\n\nВсе `include` сочетания обрабатываются после `exclude`. Это позволяет использовать `include` для добавления обратных комбинаций, которые были ранее исключены.\n\n## `jobs..strategy.fail-fast`\n\nМожно управлять обработкой сбоев заданий с помощью `jobs..strategy.fail-fast` и `jobs..continue-on-error`.\n\n`jobs..strategy.fail-fast` применяется ко всему тому. Если `jobs..strategy.fail-fast` задано значение `true` или его выражение оценивается `true`, GitHub отменит все выполняемые и очередные задания в матрице, если любое задание в матрице завершается ошибкой. По умолчанию свойство имеет значение `true`.\n\n`jobs..continue-on-error` применяется к одному заданию. Если `jobs..continue-on-error` имеет значение `true`, другие задания в матрице будут продолжать выполняться, даже если задание с `jobs..continue-on-error: true` завершается сбоем.\n\nМожно использовать `jobs..strategy.fail-fast` и `jobs..continue-on-error` совместно. Например, следующий рабочий процесс запустит четыре задания. Для каждого задания `continue-on-error` определяется значением `matrix.experimental`. При сбое любого из заданий с `continue-on-error: false` все выполняемые или помещенные в очередь задания будут отменены. При сбое задания с `continue-on-error: true` другие задания не будут затронуты.\n\n```yaml\njobs:\n test:\n runs-on: ubuntu-latest\n continue-on-error: ${{ matrix.experimental }}\n strategy:\n fail-fast: true\n matrix:\n version: [6, 7, 8]\n experimental: [false]\n include:\n - version: 9\n experimental: true\n```\n\n## `jobs..strategy.max-parallel`\n\nПо умолчанию GitHub максимальное количество параллельных заданий в зависимости от доступности раннера.\n\n## `jobs..continue-on-error`\n\n`jobs..continue-on-error` применяется к одному заданию. Если `jobs..continue-on-error` имеет значение `true`, другие задания в матрице будут продолжать выполняться, даже если задание с `jobs..continue-on-error: true` завершается сбоем.\n\nПредотвращает сбой выполнения рабочего процесса при сбое задания. Установите значение `true`, чтобы разрешить выполнение рабочего процесса в случае сбоя этого задания.\n\n### Пример. Предотвращение сбоя рабочего процесса в случае сбоя определенного задания матрицы\n\nМожно разрешить сбой определенных заданий в матрице без сбоя всего рабочего процесса. Например, можно разрешить сбой экспериментального задания, у которого для `node` задано `15`, без сбоя рабочего процесса.\n\n```yaml\nruns-on: ${{ matrix.os }}\ncontinue-on-error: ${{ matrix.experimental }}\nstrategy:\n fail-fast: false\n matrix:\n node: [13, 14]\n os: [macos-latest, ubuntu-latest]\n experimental: [false]\n include:\n - node: 15\n os: ubuntu-latest\n experimental: true\n```\n\n## `jobs..container`\n\n> \\[!NOTE]\n> Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux:\n>\n> * При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu.\n> * Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить.\n\nИспользуйте `jobs..container` для создания контейнера для выполнения всех этапов задания, для которых еще не указан контейнер. При наличии этапов, которые используют действия скрипта и контейнера, действия контейнера будут выполняться как одноуровневые контейнеры в той же сети с теми же подключениями томов.\n\nЕсли `container` не задан, все этапы будут выполняться непосредственно на узле, указанном, `runs-on`, если только этап не относится к действию, настроенному на выполнение в контейнере.\n\n> \\[!NOTE]\n> Оболочка по умолчанию для `run` шагов внутри контейнера `sh` вместо `bash`. Это значение может быть изменено на [`jobs..defaults.run`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun) или [`jobs..steps[*].shell`](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell).\n\n### Пример. Выполнение задания в контейнере\n\n```yaml copy\nname: CI\non:\n push:\n branches: [ main ]\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container:\n image: node:18\n env:\n NODE_ENV: development\n ports:\n - 80\n volumes:\n - my_docker_volume:/volume_mount\n options: --cpus 1\n steps:\n - name: Check for dockerenv file\n run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nПри указании только образа контейнера можно опустить ключевое слово `image`.\n\n```yaml\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container: node:18\n```\n\n## `jobs..container.image`\n\nИспользуйте `jobs..container.image` для определения образа Docker, который будет использоваться в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.\n\n> \\[!NOTE]\n> Docker Hub обычно накладывает ограничения скорости для операций отправки и извлечения, которые повлияют на задания на локальных запусках. Однако GitHub, размещенные в runner, не подлежат этим ограничениям на основе соглашения между переменными данных.product.github %} и Docker.\n\n## `jobs..container.credentials`\n\nЕсли реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать `jobs..container.credentials`, чтобы настроить `map` для `username` и `password`. Учетные данные являются теми же значениями, которые будут предоставлены команде [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Пример: определение учетных данных для реестра контейнеров\n\n```yaml\ncontainer:\n image: ghcr.io/owner/image\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n```\n\n## `jobs..container.env`\n\nИспользуйте `jobs..container.env` для задания `map` переменных среды в контейнере.\n\n## `jobs..container.ports`\n\nИспользуйте `jobs..container.ports` для задания `array` портов для использования в контейнере.\n\n## `jobs..container.volumes`\n\nИспользуйте `jobs..container.volumes` для задания `array` томов, которые будет использовать контейнер. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.\n\nЧтобы указать том, укажите путь к источнику и назначению:\n\n`:`.\n\n`` — это имя тома или абсолютный путь на хост-компьютере, а `` — это абсолютный путь в контейнере.\n\n### Пример. Подключение томов в контейнере\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..container.options`\n\nИспользуйте `jobs..container.options` для настройки дополнительных параметров ресурса контейнера Docker. Список параметров см. в разделе [`docker create` параметров](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> Параметры `--network` и `--entrypoint` параметры не поддерживаются.\n\n## `jobs..services`\n\n> \\[!NOTE]\n> Если в рабочих процессах используются действия контейнеров Docker, контейнеры заданий или контейнеры служб, необходимо использовать средство выполнения Linux:\n>\n> * При использовании размещенных в GitHub средств выполнения необходимо применять средство выполнения Ubuntu.\n> * Если вы применяете локальные средства выполнения, необходимо использовать компьютер Linux в качестве средства выполнения, а Docker нужно установить.\n\nИспользуется для размещения контейнеров служб для задания в рабочем процессе. Контейнеры служб полезны для создания баз данных или служб кэша, таких как Redis. Средство выполнения автоматически создает сеть Docker и управляет жизненным циклом контейнеров служб.\n\nЕсли вы настраиваете задание для выполнения в контейнере или шаг использует действия контейнера, вам не нужно сопоставлять порты для доступа к службе или действию. Docker автоматически предоставляет все порты между контейнерами в одной сети моста, определяемой пользователем Docker. Вы можете напрямую ссылаться на контейнер службы по имени узла. Имя узла автоматически сопоставляется с именем метки, настроенной для службы в рабочем процессе.\n\nЕсли вы настраиваете задание для запуска непосредственно на компьютере средства выполнения, а шаг не использует действие контейнера, необходимо сопоставить все необходимые порты контейнера службы Docker с узлом Docker (компьютер средства выполнения). Доступ к контейнеру службы можно получить с помощью localhost и сопоставленного порта.\n\nДополнительные сведения о различиях между контейнерами сетевых служб см. в разделе [Взаимодействие с контейнерами служб Docker](/ru/actions/tutorials/use-containerized-services/use-docker-service-containers).\n\n### Пример. Использование localhost\n\nВ этом примере создаются две службы: nginx и redis. При указании порта контейнера, но не узла порт контейнера случайным образом назначается свободному порту на узле.\nGitHub устанавливает `${{job.services..ports}}` назначенный хост-порт в контексте. В этом примере вы можете получить доступ к портам хоста сервиса с помощью `${{ job.services.nginx.ports['80'] }}` контекстов и `${{ job.services.redis.ports['6379'] }}`\n\n```yaml\nservices:\n nginx:\n image: nginx\n # Map port 8080 on the Docker host to port 80 on the nginx container\n ports:\n - 8080:80\n redis:\n image: redis\n # Map random free TCP port on Docker host to port 6379 on redis container\n ports:\n - 6379/tcp\nsteps:\n - run: |\n echo \"Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}\"\n echo \"Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}\"\n```\n\n## `jobs..services..image`\n\nОбраз Docker для использования в качестве контейнера для выполнения действия. Значением может быть имя образа Docker Hub или имя реестра.\n\nЕсли `jobs..services..image` назначена пустая строка, служба не запустится. Это можно использовать для настройки условных служб, как показано в следующем примере.\n\n```yaml\nservices:\n nginx:\n image: ${{ options.nginx == true && 'nginx' || '' }}\n```\n\n## `jobs..services..credentials`\n\nЕсли реестру контейнеров образа требуется проверка подлинности для извлечения образа, можно использовать `jobs..container.credentials`, чтобы настроить `map` для `username` и `password`. Учетные данные являются теми же значениями, которые будут предоставлены команде [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Пример `jobs..services..credentials`\n\n```yaml\nservices:\n myservice1:\n image: ghcr.io/owner/myservice1\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n myservice2:\n image: dockerhub_org/myservice2\n credentials:\n username: ${{ secrets.DOCKER_USER }}\n password: ${{ secrets.DOCKER_PASSWORD }}\n```\n\n## `jobs..services..env`\n\nЗадает `map` переменных среды в контейнере службы.\n\n## `jobs..services..ports`\n\nЗадает `array` портов для предоставления в контейнере службы.\n\n## `jobs..services..volumes`\n\nЗадает `array` тома для используемого контейнера службы. Тома можно использовать для совместного использования данных между службами или другими этапами в задании. Можно указать именованные тома Docker, анонимные тома Docker или подключения привязок на узле.\n\nЧтобы указать том, укажите путь к источнику и назначению:\n\n`:`.\n\n`` — это имя тома или абсолютный путь на хост-компьютере, а `` — это абсолютный путь в контейнере.\n\n### Пример `jobs..services..volumes`\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..services..options`\n\nДополнительные параметры ресурса контейнера Docker. Список параметров см. в разделе [`docker create` параметров](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> Параметр `--network` не поддерживается.\n\n## `jobs..services..command`\n\nПереопределяет стандартную команду (`CMD`). Значение передаётся в виде аргументов после имени изображения в `docker create` команде. Если вы также указываете `entrypoint`, `command` то даёт аргументы к этой точке входа.\n\n### Пример `jobs..services..command`\n\n```yaml\nservices:\n mysql:\n image: mysql:8\n command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n env:\n MYSQL_ROOT_PASSWORD: test\n ports:\n - 3306:3306\n```\n\n## `jobs..services..entrypoint`\n\nПереопределяет стандартное `ENTRYPOINT`значение образа Docker . Значение — это одна строка, определяющая исполняемый файл для запуска. Используйте это, когда нужно полностью заменить входную точку изображения. Вы можете объединять `entrypoint` , `command` чтобы передавать аргументы в пользовательскую точку входа.\n\n### Пример `jobs..services..entrypoint`\n\n```yaml\nservices:\n etcd:\n image: quay.io/coreos/etcd:v3.5.17\n entrypoint: etcd\n command: >-\n --listen-client-urls http://0.0.0.0:2379\n --advertise-client-urls http://0.0.0.0:2379\n ports:\n - 2379:2379\n```\n\n## `jobs..uses`\n\nРасположение и версия повторно используемого файла рабочего процесса для запуска в качестве задания. Используйте один из следующих синтаксисов:\n\n* `$/.github/workflows/{filename}` для повторного использования рабочего процесса в одном репозитории. Это рекомендуемый синтаксис для ссылки на повторно используемый рабочий процесс в одном репозитории. Этот синтаксис недоступен в GitHub Enterprise Server.\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` для повторно используемых рабочих процессов в общедоступных и частных репозиториях.\n* `./.github/workflows/{filename}` для повторно используемых рабочих процессов в одном репозитории.\n\nПри ссылке на повторно используемый рабочий процесс и `{owner}/{repo}``@{ref}`может `{ref}` быть SHA, тег выпуска или имя ветви. Если тег выпуска и ветвь имеют то же имя, тег выпуска имеет приоритет над именем ветви. Использование sha фиксации является самым безопасным вариантом для стабильности и безопасности. Дополнительные сведения см. в разделе [Справочник по безопасному использованию](/ru/actions/reference/security/secure-use#reusing-third-party-workflows).\n\nПри ссылке на повторно используемый рабочий процесс в том же репозитории или `$/``./` (без `{owner}/{repo}` и), вызываемый рабочий процесс создается из той же фиксации, что и `@{ref}`рабочий процесс вызывающего объекта. Ссылка `$/` не должна включать `@{ref}` суффикс и `$/` недоступна в GitHub Enterprise Server. Префиксы ссылок, такие как `refs/heads` и `refs/tags` не допускаются. В этом ключевом слове нельзя использовать контексты или выражения.\n\n### Пример `jobs..uses`\n\n```yaml\njobs:\n call-workflow-1-in-local-repo:\n uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n call-workflow-2-in-local-repo:\n uses: ./.github/workflows/workflow-2.yml\n # The `$/` syntax is not available in GitHub Enterprise Server.\n call-workflow-in-same-repo-at-running-commit:\n uses: $/.github/workflows/workflow-2.yml\n call-workflow-in-another-repo:\n uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\nДополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `jobs..with`\n\nЕсли задание используется для вызова многократно используемого рабочего процесса, можно использовать `with` для предоставления карты входных данных, передаваемых в вызываемый рабочий процесс.\n\nВсе входные данные, которые вы передаете, должны соответствовать спецификациям ввода, определенным в вызываемом рабочем процессе.\n\nВ отличие от [`jobs..steps[*].with`](#jobsjob_idstepswith)того, какие входные данные передаются `jobs..with` , недоступны в виде переменных среды в вызываемом рабочем процессе. Вместо этого можно ссылаться на входные данные с помощью контекста `inputs`.\n\n### Пример `jobs..with`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n with:\n username: mona\n```\n\n## `jobs..with.`\n\nПара, состоящая из строкового идентификатора для входных данных и значения входных данных. Идентификатор должен соответствовать имени входных данных, определенных [`on.workflow_call.inputs.`](/ru/actions/reference/workflows-and-actions/metadata-syntax#inputsinput_id) в вызываемом рабочем процессе. Тип данных значения должен соответствовать типу, определенному [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) в вызываемом рабочем процессе.\n\nДопустимые контексты выражений: `github` и `needs`.\n\n## `jobs..secrets`\n\nЕсли задание используется для вызова многократно используемого рабочего процесса, можно использовать `secrets` для предоставления карты секретов, передаваемых в вызываемый рабочий процесс.\n\nВсе секретные данные, которые вы передаете, должны соответствовать именам, определенным в вызываемом рабочем процессе.\n\n### Пример `jobs..secrets`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n secrets:\n access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n```\n\n## `jobs..secrets.inherit`\n\nИспользуйте ключевое слово `inherit` для передачи всех секретов вызывающего рабочего процесса в вызываемой рабочий процесс. Сюда входят все секреты, к которым у вызывающего рабочего процесса есть доступ, то есть секреты организации, репозитория и среды. Ключевое слово `inherit` можно использовать для передачи секретов между репозиториями в одной организации или между организациями в пределах одного предприятия.\n\n### Пример `jobs..secrets.inherit`\n\n```yaml\non:\n workflow_dispatch:\n\njobs:\n pass-secrets-to-workflow:\n uses: ./.github/workflows/called-workflow.yml\n secrets: inherit\n```\n\n```yaml\non:\n workflow_call:\n\njobs:\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n - name: Use a repo or org secret from the calling workflow.\n run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}\n```\n\n## `jobs..secrets.`\n\nПара, состоящая из строкового идентификатора для секрета и значения секрета. Идентификатор должен соответствовать имени секрета, определенного [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id) в вызываемом рабочем процессе.\n\nДопустимые контексты выражений: `github`, `needs` и `secrets`.\n\n## Памятка по шаблонам фильтров\n\nСпециальные символы можно использовать в фильтрах путей, ветвей и тегов.\n\n* `*`: соответствует нулю или нескольким символам, но не соответствует символу `/`. Например, `Octo*` соответствует `Octocat`.\n* `**`: соответствует нулю или более символам.\n* `?`: соответствует нулю или одному из предыдущих символов.\n* `+`: соответствует одному или нескольким предыдущим символам.\n* `[]` Соответствует одному буквенно-цифровому символу, указанному в скобках или включенным в диапазоны. Диапазоны могут включать только `a-z`, `A-Z` и `0-9`. Например, диапазон `[0-9a-z]` соответствует любой цифре или строчной букве. Например, `[CB]at` соответствует `Cat` или `Bat`, а `[1-2]00` соответствует `100` и `200`.\n* `!`: в начале шаблона приводит к отмене предыдущих положительных шаблонов. Если не является первым символом, не имеет особого значения.\n\nСимволы `*`, `[` и `!` являются специальными символами в YAML. Если вы начинаете шаблон с `*`, `[` или `!`, необходимо заключить шаблон в кавычки. Кроме того, при использовании [последовательности потоков](https://yaml.org/spec/1.2.2/#flow-sequences) с шаблоном, содержащим `[` и (или) `]`шаблон должен быть заключен в кавычки.\n\n```yaml\n# Valid\npaths:\n - '**/README.md'\n\n# Invalid - creates a parse error that\n# prevents your workflow from running.\npaths:\n - **/README.md\n\n# Valid\nbranches: [ main, 'release/v[0-9].[0-9]' ]\n\n# Invalid - creates a parse error\nbranches: [ main, release/v[0-9].[0-9] ]\n```\n\nДополнительные сведения о синтаксисе фильтра ветвей, тегов и путей см. в разделе `on..`[](#onpushbranchestagsbranches-ignoretags-ignore),`on..`[](#onpull_requestpull_request_targetbranchesbranches-ignore) а [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore)также .\n\n### Шаблоны для сопоставления ветвей и тегов\n\n| Расписание | Description | Примеры совпадений |\n| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |\n| `feature/*` | Подстановочный знак `*` соответствует любому символу, но не соответствует косой черте (`/`). | `feature/my-branch`

`feature/your-branch` |\n| `feature/**` | Подстановочный знак `**` соответствует любому символу, включая косую черту (`/`), в именах ветвей и тегов. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` |\n| `main`

`releases/mona-the-octocat` | Соответствует точному имени ветви или тега. | `main`

`releases/mona-the-octocat` |\n| `'*'` | Соответствует всем именам ветвей и тегов, которые не содержат косую черту (`/`). Символ `*` является специальным символом в YAML. При запуске шаблона с `*` необходимо использовать кавычки. | `main`

`releases` |\n| `'**'` | Соответствует всем именам ветвей и тегов. Это поведение по умолчанию, если вы не используете фильтр `branches` или `tags`. | `all/the/branches`

`every/tag` |\n| `'*feature'` | Символ `*` является специальным символом в YAML. При запуске шаблона с `*` необходимо использовать кавычки. | `mona-feature`

`feature`

`ver-10-feature` |\n| `v2*` | Соответствует именам ветвей и тегов, начинающимся с `v2`. | `v2`

`v2.0`

`v2.9` |\n| `v[12].[0-9]+.[0-9]+` | Соответствует всем ветвям и тегам семантического управления версиями с основной версией 1 или 2. | `v1.10.1`

`v2.0.0` |\n\n### Шаблоны для сопоставления путей к файлам\n\nШаблоны путей должны соответствовать всему пути и начинаться с корневого каталога репозитория.\n\n| Расписание | Описание совпадений | Примеры совпадений |\n| ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `'*'` | Подстановочный знак `*` соответствует любому символу, но не соответствует косой черте (`/`). Символ `*` является специальным символом в YAML. При запуске шаблона с `*` необходимо использовать кавычки. | `README.md`

`server.rb` |\n| `'*.jsx?'` | Символ `?` соответствует нулю или одному из предыдущих символов. | `page.js`

`page.jsx` |\n| `'**'` | Подстановочный знак `**` соответствует любому символу, включая косую черту (`/`). Это поведение по умолчанию, если вы не используете фильтр `path`. | `all/the/files.md` |\n| `'*.js'` | Подстановочный знак `*` соответствует любому символу, но не соответствует косой черте (`/`). Соответствует всем файлам `.js` в корне репозитория. | `app.js`

`index.js` |\n| `'**.js'` | Соответствует всем файлам `.js` в репозитории. | `index.js`

`js/index.js`

`src/js/app.js` |\n| `docs/*` | Все файлы в корневом каталоге `docs` только в корне репозитория. | `docs/README.md`

`docs/file.txt` |\n| `docs/**` | Все файлы в каталоге `docs` и его подкаталогах в корне репозитория. | `docs/README.md`

`docs/mona/octocat.txt` |\n| `docs/**/*.md` | Файл с суффиксом `.md` в любом месте каталога `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` |\n| `'**/docs/**'` | Любые файлы в каталоге `docs` в любом месте репозитория. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` |\n| `'**/README.md'` | Файл README.md в любом месте репозитория. | `README.md`

`js/README.md` |\n| `'**/*src/**'` | Любой файл в папке с суффиксом `src` в любом месте репозитория. | `a/src/app.js`

`my-src/code/js/app.js` |\n| `'**/*-post.md'` | Файл с суффиксом `-post.md` в любом месте репозитория. | `my-post.md`

`path/their-post.md` |\n| `'**/migrate-*.sql'` | Файл с префиксом `migrate-` и суффиксом `.sql` в любом месте репозитория. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` |\n| `'*.md'`

`'!README.md'` | Использование восклицательного знака (`!`) перед шаблоном отменяет его. Если файл соответствует шаблону, а также соответствует отрицательному шаблону, определенному позже в файле, файл не будет включен. | `hello.md`

|\n| *Не совпадает*

`README.md`

`docs/hello.md` | | |\n| `'*.md'`

`'!README.md'`

`README*` | Шаблоны проверяются последовательно. Шаблон, который отрицает предыдущий шаблон, будет повторно включать пути к файлам. | `hello.md`

`README.md`

`README.doc` |"}