# Справочник по контекстам Найдите информацию о контекстах, доступных в GitHub Actions рабочих процессах, включая доступные свойства, методы доступа и примеры использования. ## Доступные контексты | Имя контекста | Тип | Описание | | ------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | Сведения об экземпляре рабочего процесса. Дополнительные сведения см. в разделе о [контексте `github`](#github-context). | | `env` | `object` | Содержит переменные, заданные в рабочем процессе, задании или шаге. Дополнительные сведения см. в разделе о [контексте `env`](#env-context). | | `vars` | `object` | Содержит переменные, заданные на уровне репозитория, организации или среды. Дополнительные сведения см. в разделе о [контексте `vars`](#vars-context). | | `job` | `object` | Сведения о выполняемом в данный момент задании. Дополнительные сведения см. в разделе о [контексте `job`](#job-context). | | `jobs` | `object` | Только для повторно используемых рабочих процессов содержит выходные данные заданий из повторно используемых рабочих процессов. Дополнительные сведения см. в разделе о [контексте `jobs`](#jobs-context). | | `steps` | `object` | Сведения о шагах, которые были выполнены в текущем задании. Дополнительные сведения см. в разделе о [контексте `steps`](#steps-context). | | `runner` | `object` | Сведения о средстве выполнения, в котором выполняется текущее задание. Дополнительные сведения см. в разделе о [контексте `runner`](#runner-context). | | `secrets` | `object` | Содержит имена и значения секретов, доступных для экземпляра рабочего процесса. Дополнительные сведения см. в разделе о [контексте `secrets`](#secrets-context). | | `strategy` | `object` | Сведения о стратегии выполнения матрицы для текущего задания. Дополнительные сведения см. в разделе о [контексте `strategy`](#strategy-context). | | `matrix` | `object` | Содержит свойства матрицы, определенные в рабочем процессе, который применяется к текущему заданию. Дополнительные сведения см. в разделе о [контексте `matrix`](#matrix-context). | | `needs` | `object` | Содержит выходные данные всех заданий, которые определены как зависимые для текущего задания. Дополнительные сведения см. в разделе о [контексте `needs`](#needs-context). | | `inputs` | `object` | Содержит входные данные повторно используемых или вручную активируемых рабочих процессов. Дополнительные сведения см. в разделе о [контексте `inputs`](#inputs-context). | В выражении доступ к данным контекста можно получить с помощью одного из двух видов синтаксиса. * Синтаксис индексов: `github['sha']` * Синтаксис разыменования свойств: `github.sha` Чтобы использовать синтаксис разыменования свойств, имя свойства должно начинаться с буквы или `_` и содержать только буквенно-цифровые символы, `-` или `_`. Если вы пытаетесь разыменовать несуществующее свойство, оно будет оцениваться как пустая строка. ### Когда используются контексты GitHub Actions включает набор переменных, *называемых контекстами* , и аналогичный набор переменных, *называемых переменными по умолчанию*. Эти переменные предназначены для использования в разных точках рабочего процесса: * **Переменные среды по умолчанию:** эти переменные среды существуют только в средстве выполнения, выполняющего задание. Дополнительные сведения см. в разделе [Справочник по переменным](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/variables). * **Контексты.** Вы можете использовать большинство контекстов в любой точке рабочего процесса, включая, когда *переменные* по умолчанию будут недоступны. Например, можно использовать контексты с выражениями для выполнения начальной обработки перед маршрутизацией задания в средство выполнения тестов. Это позволяет использовать контекст с условным ключевым словом `if`, чтобы определить, следует ли выполнять шаг. После выполнения задания можно также извлечь переменные контекста из средства выполнения тестов, которое выполняет задание, например `runner.os`. Дополнительные сведения о том, где можно использовать различные контексты в рабочем процессе, см. в разделе ["Доступность контекста](#context-availability)". В следующем примере показано, как эти различные типы переменных можно использовать вместе в задании: ```yaml copy name: CI on: push jobs: prod-check: if: ${{ github.ref == 'refs/heads/main' }} runs-on: ubuntu-latest steps: - run: echo "Deploying to production server on branch $GITHUB_REF" ``` В этом примере инструкция `if` проверяет контекст [`github.ref`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), чтобы определить имя текущей ветви; если используется имя `refs/heads/main`, то выполняются последующие шаги. `if` Проверка обрабатывается с GitHub Actionsпомощью , и задание отправляется бегущему только если результат равен `true`. После отправки задания в средство выполнения выполняется шаг и ссылается на [`$GITHUB_REF`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/variables) переменную из средства выполнения. ### Доступность контекста В экземпляре рабочего процесса доступны различные контексты. Например, контекст `secrets` может использоваться только в определенных местах задания. Кроме того, некоторые функции также могут использоваться только в определенных местах. Например, функция `hashFiles` доступна не везде. В следующей таблице перечислены ограничения, в которых можно использовать каждый контекст и специальную функцию в рабочем процессе. Перечисленные контексты доступны только для заданного ключа рабочего процесса и не могут использоваться в другом месте. Если эти сведения не приводятся, значит функцию можно использовать где угодно. | Ключ рабочего процесса | Контекст | Специальные функции | | -------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ | | `run-name` | `github, inputs, vars` | нет | | `concurrency` | `github, inputs, vars` | нет | | `env` | `github, secrets, inputs, vars` | нет | | `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | нет | | `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | нет | | `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | нет | | `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | нет | | `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | нет | | `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | нет | | `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | нет | | `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` | | `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | нет | | `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | нет | | `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | нет | | `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | нет | | `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` | | `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..strategy` | `github, needs, vars, inputs` | нет | | `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | нет | | `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | нет | | `on.workflow_call.inputs..default` | `github, inputs, vars` | нет | | `on.workflow_call.outputs..value` | `github, jobs, vars, inputs` | нет | ### Пример: вывод данных контекста в журнал Содержимое контекстов можно выводить в журнал для отладки. Для вывода объектов JSON в журнал в правильном формате требуется [функция `toJSON`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#tojson). > \[!WARNING] > При использовании всего `github` контекста следует учитывать, что он включает конфиденциальную информацию, например `github.token`. GitHub маскирует секреты при печати в консоль, но при экспорте или печати контекста следует соблюдать осторожность. ```yaml copy name: Context testing on: push jobs: dump_contexts_to_log: runs-on: ubuntu-latest steps: - name: Dump GitHub context env: GITHUB_CONTEXT: ${{ toJson(github) }} run: echo "$GITHUB_CONTEXT" - name: Dump job context env: JOB_CONTEXT: ${{ toJson(job) }} run: echo "$JOB_CONTEXT" - name: Dump steps context env: STEPS_CONTEXT: ${{ toJson(steps) }} run: echo "$STEPS_CONTEXT" - name: Dump runner context env: RUNNER_CONTEXT: ${{ toJson(runner) }} run: echo "$RUNNER_CONTEXT" - name: Dump strategy context env: STRATEGY_CONTEXT: ${{ toJson(strategy) }} run: echo "$STRATEGY_CONTEXT" - name: Dump matrix context env: MATRIX_CONTEXT: ${{ toJson(matrix) }} run: echo "$MATRIX_CONTEXT" ``` ## Контекст `github` Контекст `github` содержит сведения об экземпляре рабочего процесса и событии, которое запустило этот экземпляр. Большинство данных контекста `github` можно считывать в переменных среды. Дополнительные сведения о переменных среды см. в разделе [Хранение сведений в переменных](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables). > \[!WARNING] > При использовании всего `github` контекста следует учитывать, что он включает конфиденциальную информацию, например `github.token`. GitHub маскирует секреты при печати в консоль, но при экспорте или печати контекста следует соблюдать осторожность. > \[!WARNING] > При создании рабочих процессов и действий следует всегда учитывать, может ли код выполнять ненадежные входные данные от возможных злоумышленников. Некоторые контексты следует считать непроверенными, так как злоумышленники могут вставить собственное вредоносное содержимое. Дополнительные сведения см. в разделе [Справочник по безопасному использованию](/ru/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks). | Имя свойства | Тип | Описание | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | Контекст верхнего уровня, доступный во время любого задания или шага рабочего процесса. Этот объект содержит все свойства, перечисленные ниже. | | `github.action` | `string` | Имя выполняемого в настоящий момент действия или параметр [`id`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) шага. | | GitHubудаляет специальные символы и использует имя`__run`, когда текущий шаг запускает скрипт без .`id` Если одно действие используется в задании несколько раз, к имени добавляется суффикс в виде знака подчеркивания и порядкового номера после него. Например, первый сценарий, который вы запустите, будет иметь имя `__run`, а второй сценарий будет называться `__run_2`. Аналогично второй вызов `actions/checkout` будет называться `actionscheckout2`. | | | | `github.action_path` | `string` | Путь к расположению действия. Это свойство поддерживается только в составных действиях. Вы можете использовать этот путь для доступа к файлам, находящимся в том же репозитории, что и действие, например, переключив каталоги на путь (используя соответствующую переменную среды): `cd "$GITHUB_ACTION_PATH"`. Для получения дополнительной информации о переменных среды см. [Справочник по безопасному использованию](/ru/enterprise-server@3.22/actions/reference/security/secure-use#use-an-intermediate-environment-variable). | | `github.action_ref` | `string` | Для шага, в котором выполняется действие, это номер выполняемого действия. Например, `v2`.

Не используйте в ключевом слове `run` . Чтобы сделать этот контекст работой с составными действиями, обратитесь к нему в `env` контексте составного действия. | | `github.action_repository` | `string` | Для шага, в котором выполняется действие, это имя владельца и репозитория, где находится действие. Например, `actions/checkout`.

Не используйте в ключевом слове `run` . Чтобы сделать этот контекст работой с составными действиями, обратитесь к нему в `env` контексте составного действия. | | `github.action_status` | `string` | Текущий результат составного действия. | | `github.actor` | `string` | Имя пользователя, активировав начальное выполнение рабочего процесса. Если рабочий процесс выполняется повторно, это значение может отличаться от `github.triggering_actor`. В повторных запусках рабочих процессов будут использоваться привилегии `github.actor`, даже если субъект, инициировавший повторный запуск (`github.triggering_actor`), имеет другие привилегии. | | `github.actor_id` | `string` | Идентификатор учетной записи пользователя или приложения, активировавшего начальное выполнение рабочего процесса. Например, `1234567`. Обратите внимание, что это отличается от имени пользователя субъекта. | | `github.api_url` | `string` | URL-адрес GitHub REST API. | | | | | | `github.artifacts` | `string` | Путь к файлу, который определяет артефакты рабочего процесса для текущего шага. Напишите одно объявление на строку, чтобы определить файлы или ссылки на дайджест OCI в качестве артефактов рабочего процесса. Дополнительные сведения см. в разделе [Команды рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#declaring-workflow-artifacts). | | `github.artifacts_list` | `string` | Путь к файлу только для чтения с метаданными артефакта рабочего процесса для текущего задания в формате JSON. Дополнительные сведения см. в разделе [Команды рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#reading-workflow-artifacts). | | | | | | `github.base_ref` | `string` | | | `base_ref` или целевая ветвь запроса на включение внесенных изменений в экземпляре рабочего процесса. Это свойство доступно, только если экземпляр рабочего процесса был запущен событием `pull_request` или `pull_request_target`. | | | | `github.env` | `string` | В средстве выполнения это путь к файлу, в котором задаются переменные среды для команд рабочего процесса. Этот файл уникален для каждого шага в задании. Дополнительные сведения см. в разделе [Команды рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable). | | `github.event` | `object` | Все полезные данные веб-перехватчика события. Этот контекст дает доступ к отдельным свойствам события. Этот объект идентичен полезным данным веб-перехватчика события, которое запустило экземпляр рабочего процесса, и у каждого события он свой. Вебхуки для каждого GitHub Actions события связаны в [AUTOTITLE.](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) Например, для экземпляра рабочего процесса, запущенного `push`[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#push), в этом объекте содержатся [полезные данные веб-перехватчика события push](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push). | | `github.event_name` | `string` | Имя события, вызвавшего запуск рабочего процесса. | | `github.event_path` | `string` | В средстве выполнения это путь к файлу, в котором содержатся все полезные данные веб-перехватчика события. | | `github.graphql_url` | `string` | URL API GitHub GraphQL. | | `github.head_ref` | `string` | | | `head_ref` или исходная ветвь запроса на включение внесенных изменений в экземпляре рабочего процесса. Это свойство доступно, только если экземпляр рабочего процесса был запущен событием `pull_request` или `pull_request_target`. | | | | `github.job` | `string` | Свойство [`job_id`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_id) текущего задания.
Примечание. Это свойство контекста задается средством выполнения Acrions и доступно только в рамках выполнения этапов (`steps`) задания. В противном случае значение этого свойства будет равно `null`. | | `github.path` | `string` | Путь к файлу, который задает системные `PATH` переменные из команд рабочего процесса. Этот файл уникален для каждого шага в задании. Дополнительные сведения см. в разделе [Команды рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path). | | `github.ref` | `string` | Полностью сформированный ссылку на ветвь или тег, активировавший выполнение рабочего процесса. Если рабочий процесс запущен по триггеру `push`, здесь указывается ссылка на отправленную ветвь или тег выпуска. Для рабочих процессов, которые `pull_request` не были объединены, это ветка слияния pull request. Если pull request был объединён, это ветка, в которую он был объединён. Если рабочий процесс запущен по триггеру `release`, здесь указывается созданный тег выпуска. Для всех остальных триггеров указывается ссылка на ветвь или тег, которые активировали запуск рабочего процесса. Это значение задается только для тех типов событий, в которых доступны ветвь или тег. Указанная ссылка полностью сформирована, что означает, что для ветвей имеется `refs/heads/`формат. Для событий pull request, кроме `pull_request_target` тех случаев, которые не были объединены, это .`refs/pull//merge` | | `pull_request_target`события имеют базовая ветвь`ref`. Для тегов это `refs/tags/`. Например, `refs/heads/feature-branch-1`. Для получения дополнительной информации о ветках слияния pull request см. [Запросы на слияние](/ru/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). | | | | `github.ref_name` | `string` | Короткое имя ссылки ветви или тега, активировав выполнение рабочего процесса. Это значение соответствует имени ветви или тега, отображаемого на GitHub. Например, `feature-branch-1`.

Для pull-запросов, которые не были объединены, формат — `/merge`. | | `github.ref_protected` | `boolean` | `true` Значение , если защита ветви настроены для ссылки, которая активировала выполнение рабочего процесса. | | `github.ref_type` | `string` | Тип ссылки, активировавшей выполнение рабочего процесса. Допустимые значения — `branch` или `tag`. | | `github.repository` | `string` | Имя владельца и репозитория. Например, `octocat/Hello-World`. | | `github.repository_id` | `string` | Идентификатор репозитория. Например, `123456789`. Обратите внимание, что это отличается от имени репозитория. | | `github.repository_owner` | `string` | Имя пользователя владельца репозитория. Например, `octocat`. | | `github.repository_owner_id` | `string` | Идентификатор учетной записи владельца репозитория. Например, `1234567`. Обратите внимание, что это отличается от имени владельца. | | `github.repositoryUrl` | `string` | URL-адрес Git в репозитории. Например, `git://github.com/octocat/hello-world.git`. | | `github.retention_days` | `string` | Количество дней, в течение которых рабочий процесс выполняет журналы и артефакты. | | `github.run_id` | `string` | Уникальный номер каждого запуска рабочего процесса в репозитории. Он не изменяется при повторном запуске рабочего процесса. | | `github.run_number` | `string` | Уникальный номер для каждого запуска определенного рабочего процесса в репозитории. Он начинается с цифры 1 для первого запуска рабочего процесса и увеличивается с каждым новым запуском. Он не изменяется при повторном запуске рабочего процесса. | | `github.run_attempt` | `string` | Уникальное число для каждой попытки конкретного рабочего процесса, выполняемого в репозитории. Первая попытка обозначается номером 1, для всех последующих номер увеличивается. | | `github.secret_source` | `string` | Источник секрета, используемого в рабочем процессе. Возможные значения — `None`, `Actions`, или `Dependabot`. | | `github.server_url` | `string` | URL-адрес сервера GitHub. Например: `https://github.com`. | | `github.sha` | `string` | SHA фиксации, инициировавшей рабочий процесс. Значение этой фиксации SHA зависит от события, активирующего рабочий процесс. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). Например, `ffac537e6cbbf934b08745a378932722df287a53`. | | `github.token` | `string` | Маркер для проверки подлинности от имени приложения GitHub, установленного в репозитории. Эта функциональность равнозначна секрету `GITHUB_TOKEN`. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token).
Примечание. Это свойство контекста задается средством выполнения Acrions и доступно только в рамках выполнения этапов (`steps`) задания. В противном случае значение этого свойства будет равно `null`. | | `github.triggering_actor` | `string` | Имя пользователя, запустившего экземпляр рабочего процесса. Если рабочий процесс выполняется повторно, это значение может отличаться от `github.actor`. В повторных запусках рабочих процессов будут использоваться привилегии `github.actor`, даже если субъект, инициировавший повторный запуск (`github.triggering_actor`), имеет другие привилегии. | | `github.workflow` | `string` | Имя рабочего процесса. Если в файле рабочего процесса не указано свойство `name`, в качестве его значения используется полный путь к файлу рабочего процесса в репозитории. | | `github.workflow_ref` | `string` | Путь ссылки к рабочему процессу. Например, `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`. | | `github.workflow_sha` | `string` | Фиксация SHA для файла рабочего процесса. | | `github.workspace` | `string` | Рабочий каталог по умолчанию в средстве выполнения для шагов и расположение по умолчанию репозитория при использовании [`checkout`](https://github.com/actions/checkout) действия. | ### Пример содержимого контекста `github` Следующий пример контекста взят из экземпляра рабочего процесса, запущенного событием `push`. В этом примере объект `event` усечен, так как он идентичен [полезным данным веб-перехватчика `push`](/ru/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push). > \[!NOTE] > Это только пример. Содержимое контекста зависит от выполняемого рабочего процесса. Контексты, объекты и свойства во многом зависят от условий выполнения рабочего процесса. ```json { "token": "***", "job": "dump_contexts_to_log", "ref": "refs/heads/my_branch", "sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369", "repository": "octocat/hello-world", "repository_owner": "octocat", "repositoryUrl": "git://github.com/octocat/hello-world.git", "run_id": "1536140711", "run_number": "314", "retention_days": "90", "run_attempt": "1", "actor": "octocat", "workflow": "Context testing", "head_ref": "", "base_ref": "", "event_name": "push", "event": { ... }, "server_url": "https://github.com", "api_url": "https://api.github.com", "graphql_url": "https://api.github.com/graphql", "ref_name": "my_branch", "ref_protected": false, "ref_type": "branch", "secret_source": "Actions", "workspace": "/home/runner/work/hello-world/hello-world", "action": "github_step", "event_path": "/home/runner/work/_temp/_github_workflow/event.json", "action_repository": "", "action_ref": "", "path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602", "env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602" } ``` ### Пример использования контекста `github` В этом примере задание выполняется с помощью контекста `github.event_name`, только если экземпляр рабочего процесса был запущен событием `pull_request`. ```yaml copy name: Run CI on: [push, pull_request] jobs: normal_ci: runs-on: ubuntu-latest steps: - name: Run normal CI run: echo "Running normal CI" pull_request_ci: runs-on: ubuntu-latest if: ${{ github.event_name == 'pull_request' }} steps: - name: Run PR CI run: echo "Running PR only CI" ``` ## Контекст `env` Контекст `env` содержит переменные, заданные в рабочем процессе, задании или шаге. Он не содержит переменные, унаследованные процессом выполнения. Дополнительные сведения о настройке переменных в рабочем процессе см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env). Вы можете получить значения переменных, хранящихся в `env` контексте, и использовать эти значения в файле рабочего процесса. Контекст можно использовать `env` в любом ключе в шаге рабочего процесса, за исключением ключей и `id` ключей`uses`. Дополнительные сведения о синтаксисе шага см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsteps). Если вы хотите использовать значение переменной внутри средства выполнения, используйте обычный метод операционной системы runner для чтения переменных среды. | Имя свойства | Тип | Описание | | ---------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `env` | `object` | Этот контекст меняется для каждого шага в задании. Доступ к этому контексту можно получить из любого шага задания. Этот объект содержит свойства, перечисленные ниже. | | `env.` | `string` | Значение конкретной переменной среды. | ### Пример содержимого контекста `env` Содержимое контекста `env` — это сопоставление имен переменных с их значениями. Содержимое контекста зависит от места, где он используется в экземпляре рабочего процесса. В этом примере `env` контекст содержит две переменные. ```json { "first_name": "Mona", "super_duper_var": "totally_awesome" } ``` ### Пример использования контекста `env` В этом примере рабочего процесса показаны переменные, заданные в контексте `env` на уровне рабочего процесса, задания и шага. Затем `${{ env.VARIABLE-NAME }}` синтаксис используется для получения значений переменных в отдельных шагах рабочего процесса. При определении нескольких переменных среды с тем же именем GitHub использует самую конкретную переменную. Например, переменная среды, определенная на шаге, переопределяет переменные задания и среды рабочего процесса с тем же именем, а шаг выполняется. Переменная среды, определенная для задания, переопределяет переменную рабочего процесса с тем же именем, а задание выполняется. ```yaml copy name: Hi Mascot on: push env: mascot: Mona super_duper_var: totally_awesome jobs: windows_job: runs-on: windows-latest steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Mona - run: echo 'Hi ${{ env.mascot }}' # Hi Octocat env: mascot: Octocat linux_job: runs-on: ubuntu-latest env: mascot: Tux steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Tux ``` ## Контекст `vars` Контекст `vars` содержит настраиваемые переменные конфигурации, заданные на уровнях организации, репозитория и среды. Дополнительные сведения об определении переменных конфигурации для использования в нескольких рабочих процессах см. в разделе [Хранение сведений в переменных](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows). ### Пример содержимого контекста `vars` Содержимое контекста `vars` — это сопоставление имен переменных конфигурации с их значениями. ```json { "mascot": "Mona" } ``` ### Пример использования контекста `vars` В этом примере рабочего процесса показано, как переменные конфигурации, заданные на уровне репозитория, среды или организации, автоматически доступны с помощью контекста `vars` . > \[!NOTE] > Переменные конфигурации на уровне среды автоматически доступны после того, как среда объявляется средством выполнения. Если переменная конфигурации не задана, возвращаемое значение контекста, ссылающееся на переменную, будет пустой строкой. В следующем примере показано использование переменных конфигурации с контекстом `vars` в рабочем процессе. Каждая из следующих переменных конфигурации определена на уровне репозитория, организации или среды. ```yaml copy on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }} ``` ## Контекст `job` Контекст `job` содержит сведения о выполняемом в данный момент задании. | Имя свойства | Тип | Описание | | ----------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `job` | `object` | Этот контекст меняется для каждого задания в экземпляре рабочего процесса. Доступ к этому контексту можно получить из любого шага задания. Этот объект содержит все свойства, перечисленные ниже. | | | | | | `job.container` | `object` | Сведения о контейнере задания. Дополнительные сведения о контейнерах см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer). | | `job.container.id` | `string` | Идентификатор контейнера. | | `job.container.network` | `string` | Идентификатор сети контейнеров. Средство выполнения создает сеть, которая используется всеми контейнерами в задании. | | `job.services` | `object` | Контейнеры служб, созданные для задания. Дополнительные сведения о контейнерах служб см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices). | | `job.services..id` | `string` | Идентификатор контейнера службы. | | `job.services..network` | `string` | Идентификатор сети контейнеров служб. Средство выполнения создает сеть, которая используется всеми контейнерами в задании. | | `job.services..ports` | `object` | Доступные порты контейнера службы. | | `job.status` | `string` | текущее состояние задания; Возможные значения: `success`, `failure`или `cancelled`. | | `job.workflow_ref` | `string` | Полная ссылка на файл рабочего процесса, который определяет текущую задачу. Например, `octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`. Для задач, определённых напрямую в файле рабочего процесса, это то же самое, что `github.workflow_ref`и . Для заданий, определённых [в AUTOTITLE,](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) это относится к повторно используемому файлу рабочего процесса. (недоступно на GitHub Enterprise Server) | | `job.workflow_sha` | `string` | Коммит SHA файла рабочего процесса, который определяет текущую задачу. (недоступно на GitHub Enterprise Server) | | `job.workflow_repository` | `string` | Репозиторий, `owner/repo` содержащий файл рабочего процесса, определяющий текущую задачу. Например, `octo-org/octo-repo`. (недоступно на GitHub Enterprise Server) | | `job.workflow_file_path` | `string` | Путь файла рабочего процесса, который определяет текущую задачу относительно корня репозитория. Например, `.github/workflows/deploy.yml`. (недоступно на GitHub Enterprise Server) | ### Пример содержимого контекста `job` В этом примере контекста `job` используется контейнер службы PostgreSQL с сопоставленными портами. Если в задании не используются контейнеры или сервисные контейнеры, `job` контекст содержит `status`только . Свойства `check_run_id` идентичности и рабочих процессов (`workflow_ref`, `workflow_sha`, `workflow_repository``workflow_file_path`, ) недоступны на GitHub Enterprise Server. ```json { "status": "success", "check_run_id": 51725241954, "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main", "workflow_sha": "abc123def456789abc123def456789abc123def4", "workflow_repository": "octo-org/octo-repo", "workflow_file_path": ".github/workflows/deploy.yml", "container": { "network": "github_network_53269bd575974817b43f4733536b200c" }, "services": { "postgres": { "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105", "ports": { "5432": "49153" }, "network": "github_network_53269bd575974817b43f4733536b200c" } } } ``` ### Пример использования контекста `job` В этом примере рабочего процесса настраивается контейнер службы PostgreSQL и порт 5432 в контейнере службы автоматически сопоставляется со случайным выбранным доступным портом на узле. Контекст `job` используется для получения номера порта, назначенного на узле. ```yaml copy name: PostgreSQL Service Example on: push jobs: postgres-job: runs-on: ubuntu-latest services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 ports: # Maps TCP port 5432 in the service container to a randomly chosen available port on the host. - 5432 steps: - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }} - run: echo "Run tests against Postgres" ``` ### Пример использования `job` идентичности контекстного рабочего процесса > \[!NOTE] > Свойства `job.workflow_*` контекста недоступны на GitHub Enterprise Server. Этот пример многоразового рабочего процесса использует `job.workflow_repository` и `job.workflow_sha` проверяет собственный исходный код, а не репозиторий звонящего. Это полезно, когда многоразовый рабочий процесс должен получить доступ к файлам, расположенным вместе с определением рабочего процесса. ```yaml copy # In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml) name: Reusable deploy workflow on: workflow_call: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: repository: ${{ job.workflow_repository }} ref: ${{ job.workflow_sha }} - run: echo "Deploying from ${{ job.workflow_ref }}" - run: echo "Workflow file path is ${{ job.workflow_file_path }}" ``` ## Контекст `jobs` Контекст `jobs` доступен только в повторно используемых рабочих процессах и может использоваться только для задания выходных данных для повторно используемого рабочего процесса. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). | Имя свойства | Тип | Описание | | ------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `jobs` | `object` | Доступен только в повторно используемых рабочих процессах и может использоваться только для задания выходных данных для повторно используемого рабочего процесса. Этот объект содержит все свойства, перечисленные ниже. | | `jobs..result` | `string` | Результат задания в повторно используемом рабочем процессе. Возможные значения: `success`, `failure`, `cancelled` или `skipped`. | | `jobs..outputs` | `object` | Набор выходных данных задания в повторно используемом рабочем процессе. | | `jobs..outputs.` | `string` | Значение определенных выходных данных для задания в повторно используемых рабочих процессах. | ### Пример содержимого контекста `jobs` Этот пример контекста `jobs` содержит результат и выходные данные задания из повторно используемых рабочих процессов. ```json { "example_job": { "result": "success", "outputs": { "output1": "hello", "output2": "world" } } } ``` ### Пример использования контекста `jobs` В этом примере повторно используемый рабочий процесс использует контекст `jobs` для задания выходных данных для повторно используемого рабочего процесса. Обратите внимание, как выходные данные передаются из шагов в задание, а затем в триггер `workflow_call`. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). ```yaml copy name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT ``` ## Контекст `steps` В контексте `steps` содержатся сведения об уже запущенных шагах в текущем задании с указанным свойством [`id`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid). | Имя свойства | Тип | Описание | | --------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `steps` | `object` | Этот контекст меняется для каждого шага в задании. Доступ к этому контексту можно получить из любого шага задания. Этот объект содержит все свойства, перечисленные ниже. | | `steps..outputs` | `object` | Набор выходных данных, определенных для шага. Дополнительные сведения см. в разделе [Справочник по синтаксису метаданных](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#outputs-for-docker-container-and-javascript-actions). | | `steps..conclusion` | `string` | Результат завершенного шага после применения [`continue-on-error`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error). Возможные значения: `success`, `failure`, `cancelled` или `skipped`. Если шаг `continue-on-error` завершается сбоем, то `outcome` имеет значение `failure`, однако последнее свойство `conclusion` имеет значение `success`. | | `steps..outcome` | `string` | Результат завершенного шага до применения [`continue-on-error`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error). Возможные значения: `success`, `failure`, `cancelled` или `skipped`. Если шаг `continue-on-error` завершается сбоем, то `outcome` имеет значение `failure`, однако последнее свойство `conclusion` имеет значение `success`. | | `steps..outputs.` | `string` | Значение определенного набора выходных данных. | ### Пример содержимого контекста `steps` В этом примере контекста `steps` показаны два предыдущих шага с заданным свойством [`id`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid). У первого шага свойство `id` называлось `checkout`, у второго — `generate_number`. Выходными данными шага `generate_number` был номер `random_number`. ```json { "checkout": { "outputs": {}, "outcome": "success", "conclusion": "success" }, "generate_number": { "outputs": { "random_number": "1" }, "outcome": "success", "conclusion": "success" } } ``` ### Пример использования контекста `steps` В этом примере рабочего процесса в качестве выходных данных одного шага создается случайное число, а на последующем шаге эти выходные данные считываются с помощью контекста `steps`. ```yaml copy name: Generate random failure on: push jobs: randomly-failing-job: runs-on: ubuntu-latest steps: - name: Generate 0 or 1 id: generate_number run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT - name: Pass or fail run: | if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi ``` ## Контекст `runner` Контекст `runner` содержит сведения о средстве выполнения, которое запускает текущее задание. | Имя свойства | Тип | Описание | | -------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `runner` | `object` | Этот контекст меняется для каждого задания в экземпляре рабочего процесса. Этот объект содержит все свойства, перечисленные ниже. | | `runner.name` | `string` | Имя средства выполнения задания. Это имя может не быть уникальным в рабочем процессе, выполняемом в качестве средств выполнения на уровне репозитория и организации, может использовать то же имя. | | `runner.os` | `string` | Операционная система средства выполнения тестов, выполняющего задание. Возможные значения: `Linux`, `Windows`или `macOS`. | | `runner.arch` | `string` | Архитектура средства выполнения задания. Возможные значения: `X86`, `X64`, `ARM` или `ARM64`. | | `runner.temp` | `string` | Путь к временному каталогу в средстве выполнения. Этот каталог очищается в начале и конце каждого задания. Обратите внимание, что файлы не удаляются, если у учетной записи пользователя средства выполнения нет разрешения на их удаление. | | `runner.tool_cache` | `string` | Путь к каталогу, содержащему предварительно установленные средства для GitHubразмещенных средств выполнения. Дополнительные сведения см. в разделе [Средства выполнения тестов, размещенные в GitHub](/ru/enterprise-server@3.22/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images). | | `runner.debug` | `string` | Это делается только в том случае, если [ведение журнала отладки](/ru/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging) включено и всегда имеет значение `1`. Это может быть полезно в качестве индикатора для включения дополнительной отладки или подробного ведения журнала в ваших шагах задания. | | `runner.environment` | `string` | Среда выполнения задания. Возможные значения: `github-hosted` для управляемых GitHub средств выполнения, предоставляемых GitHub, а `self-hosted` также для локальных модулей выполнения, настроенных владельцем репозитория. | ### Пример содержимого контекста `runner` Следующий пример контекста взят из раннера, размещённого на Linux GitHub. ```json { "os": "Linux", "arch": "X64", "name": "GitHub Actions 2", "tool_cache": "/opt/hostedtoolcache", "temp": "/home/runner/work/_temp" } ``` ### Пример использования контекста `runner` В этом примере рабочего процесса с помощью контекста `runner` задается путь к временному каталогу для записи журналов, а если рабочий процесс завершается сбоем, эти журналы отправляются в качестве артефакта. ```yaml copy name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Build with logs run: | mkdir ${{ runner.temp }}/build_logs echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs exit 1 - name: Upload logs on fail if: ${{ failure() }} uses: actions/upload-artifact@v3 with: name: Build failure logs path: ${{ runner.temp }}/build_logs ``` ## Контекст `secrets` Контекст `secrets` содержит имена и значения секретов, доступных для экземпляра рабочего процесса. Контекст `secrets` недоступен для составных действий из-за причин безопасности. Если вы хотите передать секрет составным действиям, это необходимо сделать явным образом в качестве входных данных. Дополнительные сведения о секретах см. в разделе [Использование секретов в GitHub Actions](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). `GITHUB_TOKEN` — это секрет, который автоматически создается для каждого экземпляра рабочего процесса и всегда включается в контекст `secrets`. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token). > \[!WARNING] > Если секрет используется в задании рабочего процесса, GitHub автоматически редактирует секреты, напечатанные в журнале. Не следует намеренно печатать секреты в журнале. | Имя свойства | Тип | Описание | | ----------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `secrets` | `object` | Этот контекст одинаков для каждого задания в экземпляре рабочего процесса. Доступ к этому контексту можно получить из любого шага задания. Этот объект содержит все свойства, перечисленные ниже. | | `secrets.GITHUB_TOKEN` | `string` | Автоматически созданный токен для каждого экземпляра рабочего процесса. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token). | | `secrets.` | `string` | Значение определенного секрета. | ### Пример содержимого контекста `secrets` В следующем примере содержимого контекста `secrets` показан токен `GITHUB_TOKEN` с автоматической проверкой, а также два других секрета, доступных экземпляру рабочего процесса. ```json { "github_token": "***", "NPM_TOKEN": "***", "SUPERSECRET": "***" } ``` ### Пример использования контекста `secrets` В этом примере рабочий [процесс использует интерфейс командной строки](/ru/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli) GitHub, для которого требуется `GITHUB_TOKEN` значение входного `GH_TOKEN` параметра: ```yaml copy name: Open new issue on: workflow_dispatch jobs: open-issue: runs-on: ubuntu-latest permissions: contents: read issues: write steps: - run: | gh issue --repo ${{ github.repository }} \ create --title "Issue title" --body "Issue body" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` ## Контекст `strategy` Для рабочих процессов с матрицей контекст `strategy` содержит сведения о стратегии выполнения матрицы для текущего задания. | Имя свойства | Тип | Описание | | ------------------------------------------------------------------------------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `strategy` | `object` | Этот контекст меняется для каждого задания в экземпляре рабочего процесса. Доступ к этому контексту можно получить из любого задания или шага рабочего процесса. Этот объект содержит все свойства, перечисленные ниже. | | `strategy.fail-fast` | `boolean` | При оценке `true`этого все выполняемые задания отменяются, если любое задание в матрице завершается сбоем. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategyfail-fast). | | `strategy.job-index` | `number` | Индекс текущего задания в матрице. | | **Примечание.** Это число с отсчетом от нуля. Индекс первого задания в матрице равен `0`. | | | | `strategy.job-total` | `number` | Общее количество заданий в матрице. | | **Примечание.** Это **не** число с отсчетом от нуля. Например, для матрицы с четырьмя заданиями `job-total` имеет значение `4`. | | | | `strategy.max-parallel` | `number` | Максимальное число заданий, которые могут выполняться одновременно при использовании стратегии заданий `matrix`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymax-parallel). | ### Пример содержимого контекста `strategy` В следующем примере содержимое контекста `strategy` взято из последнего задания в матрице с четырьмя заданиям. Обратите внимание на разницу между числом `job-index` с отсчетом от нуля и свойством `job-total`, которое не отсчитывается от нуля. ```json { "fail-fast": true, "job-index": 3, "job-total": 4, "max-parallel": 4 } ``` ### Пример использования контекста `strategy` В этом примере рабочего процесса с помощью свойства `strategy.job-index` задается уникальное имя файла журнала для каждого задания в матрице. ```yaml copy name: Test strategy on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: test-group: [1, 2] node: [14, 16] steps: - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt - name: Upload logs uses: actions/upload-artifact@v3 with: name: Build log for job ${{ strategy.job-index }} path: test-job-${{ strategy.job-index }}.txt ``` ## Контекст `matrix` Для рабочих процессов с матрицей контекст `matrix` содержит свойства матрицы, определенные в файле рабочего процесса, который применяется к текущему заданию. Например, если настроить матрицу с ключами `os` и `node`, объект контекста `matrix` включает свойства `os` и `node` со значениями, которые используются для текущего задания. В контексте `matrix` нет стандартных свойств, а есть только те, что определены в файле рабочего процесса. | Имя свойства | Тип | Описание | | ------------------------ | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `matrix` | `object` | Этот контекст доступен только для заданий в матрице и меняется для каждого задания в экземпляре рабочего процесса. Доступ к этому контексту можно получить из любого задания или шага рабочего процесса. Этот объект содержит свойства, перечисленные ниже. | | `matrix.` | `string` | Значение свойства matrix. | ### Пример содержимого контекста `matrix` В следующем примере содержимое контекста `matrix` взято из задания в матрице, у которой есть свойства `os` и `node`, определенные в рабочем процессе. Задание выполняется с сочетанием ОС `ubuntu-latest` и Node.js версии `16`. ```json { "os": "ubuntu-latest", "node": 16 } ``` ### Пример использования контекста `matrix` В этом примере рабочий процесс создает матрицу с ключами `os` и `node`. В нем для каждого задания с помощью свойства `matrix.os` задается тип средства выполнения, а с помощью свойства `matrix.node` — версия Node.js. ```yaml copy name: Test matrix on: push jobs: build: runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-latest, windows-latest] node: [14, 16] steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version ``` ## Контекст `needs` Контекст `needs` содержит выходные данные всех заданий, которые определяются как прямая зависимость текущего задания. Обратите внимание, что это неявно зависимые задания (например, зависимые задания зависимых заданий). Дополнительные сведения об определении зависимостей заданий см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds). | Имя свойства | Тип | Описание | | -------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `needs` | `object` | Этот контекст заполняется только для экземпляров рабочих процессов с зависимыми заданиями и меняется для каждого задания в рабочем процессе. Доступ к этому контексту можно получить из любого задания или шага рабочего процесса. Этот объект содержит все свойства, перечисленные ниже. | | `needs.` | `object` | Одно задание, от которого зависит текущее задание. | | `needs..outputs` | `object` | Набор выходных данных задания, от которого зависит текущее задание. | | `needs..outputs.` | `string` | Значение определенного набора выходных данных для задания, от которого зависит текущее задание. | | `needs..result` | `string` | Результат задания, от которого зависит текущее задание. Возможные значения: `success`, `failure`, `cancelled` или `skipped`. | ### Пример содержимого контекста `needs` В следующем примере содержимого контекста `needs` показаны сведения о двух заданиях, от которых зависит текущее задание. ```json { "build": { "result": "success", "outputs": { "build_id": "123456" } }, "deploy": { "result": "failure", "outputs": {} } } ``` ### Пример использования контекста `needs` В этом примере рабочего процесса есть три задания: `build`, которое выполняет сборку, `deploy`, которому требуется задание `build`, а также `debug`, которому требуются и задание `build`, и `deploy` и которое выполняется, только если в рабочем процессе произошел сбой. Задание `deploy` также использует контекст `needs` для доступа к выходным данным задания `build`. ```yaml copy name: Build and deploy on: push jobs: build: runs-on: ubuntu-latest outputs: build_id: ${{ steps.build_step.outputs.build_id }} steps: - name: Build id: build_step run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT deploy: needs: build runs-on: ubuntu-latest steps: - run: echo "Deploying build ${{ needs.build.outputs.build_id }}" debug: needs: [build, deploy] runs-on: ubuntu-latest if: ${{ failure() }} steps: - run: echo "Failed to build and deploy" ``` ## Контекст `inputs` Контекст `inputs` содержит входные свойства, передаваемые в действие, в повторно используемый рабочий процесс или в рабочий процесс, активируемый вручную. Для повторно используемых рабочих процессов входные имена и типы определяются в [`workflow_call` конфигурации](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows) события повторно используемых рабочих процессов, а входные значения передаются во [`jobs..with`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) внешний рабочий процесс, который вызывает повторно используемый рабочий процесс. Для рабочих процессов, активированных вручную, входные данные определяются в [`workflow_dispatch` конфигурации](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) события рабочего процесса. Свойства в контексте `inputs` определяются в файле рабочего процесса. Они доступны только в повторно используемых [рабочих процессах](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) или в рабочем процессе, активируемом событием.[`workflow_dispatch`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) | Имя свойства | Тип | Описание | | ------------------------------------------------ | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `inputs` | `object` | Этот контекст доступен только в повторно используемых рабочих процессах или в рабочем процессе, активируемом событием[](/ru/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)`workflow_dispatch`.[](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) Доступ к этому контексту можно получить из любого задания или шага рабочего процесса. Этот объект содержит свойства, перечисленные ниже. | | `inputs.` | | | | `string` или `number` или `boolean` или `choice` | Каждое входное значение, которое передается из внешнего рабочего процесса. | | ### Пример содержимого контекста `inputs` Следующий пример содержимого контекста `inputs` взят из рабочего процесса, в котором определены входные данные `build_id`, `deploy_target` и `perform_deploy`. ```json { "build_id": 123456768, "deploy_target": "deployment_sys_1a", "perform_deploy": true } ``` ### Пример использования контекста `inputs` в многократно используемом рабочем процессе В этом примере многократно используемого рабочего процесса с помощью контекста `inputs` получаются значения входных данных `build_id`, `deploy_target` и `perform_deploy`, которые были переданы в многократно используемый рабочий процесс из рабочего процесса вызывающего объекта. ```yaml copy name: Reusable deploy workflow on: workflow_call: inputs: build_id: required: true type: number deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ### Пример использования контекста `inputs` в рабочем процессе, активированном вручную В этом примере рабочего процесса, активируемого событием `workflow_dispatch`, используется контекста `inputs` для получения значения входных данных `build_id`, `deploy_target` и `perform_deploy`, которые были переданы в рабочий процесс. ```yaml copy on: workflow_dispatch: inputs: build_id: required: true type: string deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ## Дополнительные материалы * [Контексты](/ru/enterprise-server@3.22/actions/concepts/workflows-and-actions/contexts)