Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Сведения о переменных
Переменные предоставляют способ хранения и повторного использования нечувствительных сведений о конфигурации. Вы можете хранить любые данные конфигурации, такие как флаги компилятора, имена пользователей или имена серверов в виде переменных. Переменные интерполируются на компьютере runner, на котором выполняется рабочий процесс. Команды, выполняемые в действиях или шагах рабочего процесса, могут создавать, считывать и изменять переменные.
Вы можете задать собственные пользовательские переменные или использовать переменные среды по умолчанию, которые автоматически задают GitHub. Дополнительные сведения см. в разделе "Переменные среды по умолчанию".
Настраиваемую переменную можно задать двумя способами.
- Чтобы определить переменную среды для использования в одном рабочем процессе, можно использовать
env
ключ в файле рабочего процесса. Дополнительные сведения см. в разделе "Определение переменных среды для одного рабочего процесса". - Чтобы определить переменную конфигурации в нескольких рабочих процессах, ее можно определить на уровне организации, репозитория или среды. Дополнительные сведения см. в разделе "Определение переменных конфигурации для нескольких рабочих процессов".
Предупреждение. По умолчанию переменные отображают незамеченные в выходных данных сборки. Если вам нужна более высокая безопасность для конфиденциальной информации, например паролей, используйте вместо этого секреты. Дополнительные сведения см. в разделе "Использование секретов в GitHub Actions".
Определение переменных среды для одного рабочего процесса
Чтобы задать настраиваемую переменную среды для одного рабочего процесса, ее можно определить с помощью env
ключа в файле рабочего процесса. Область настраиваемой переменной, заданной этим методом, ограничена элементом, в котором она определена. Можно определить переменные, для которых задана область:
- Весь рабочий процесс с использованием
env
на верхнем уровне файла рабочего процесса. - Содержимое задания в рабочем процессе с использованием
jobs.<job_id>.env
. - Определенный шаг задания с использованием
jobs.<job_id>.steps[*].env
.
name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
Доступ к значениям переменных можно получить env
с помощью переменных среды runner или с помощью контекстов. В приведенном выше примере показаны три пользовательских переменных, которые используются в качестве переменных среды runner в команде echo
: $DAY_OF_WEEK
, $Greeting
и $First_Name
. Значения этих переменных задаются и ограничены на уровне рабочего процесса, задания и шага соответственно. Интерполяция этих переменных происходит на средстве выполнения.
Команды в run
шагах рабочего процесса или указанного действия обрабатываются оболочкой, используемой в средстве выполнения. Инструкции в других частях рабочего процесса обрабатываются GitHub Actions и не отправляются в средство выполнения. Вы можете использовать переменные среды выполнения или контексты в run
шагах, но в частях рабочего процесса, которые не отправляются в средство выполнения, необходимо использовать контексты для доступа к значениям переменных. Дополнительные сведения см. в разделе "Использование контекстов для доступа к значениям переменных".
Так как интерполяция переменной среды выполнения выполняется после отправки задания рабочего процесса на компьютер runner, необходимо использовать соответствующий синтаксис для оболочки, используемой в средстве выполнения. В этом примере рабочим процессом указано ubuntu-latest
. По умолчанию средства выполнения Linux используют оболочку Bash, поэтому необходимо использовать синтаксис $NAME
. По умолчанию средства выполнения Windows используют PowerShell, поэтому вы будете использовать синтаксис $env:NAME
. Дополнительные сведения о оболочках см. в разделе "Синтаксис рабочего процесса для GitHub Actions".
Соглашения об именовании для переменных среды
При установке переменной среды нельзя использовать какие-либо имена переменных среды по умолчанию. Полный список переменных среды по умолчанию см. в разделе "Переменные среды по умолчанию" ниже. Если вы пытаетесь переопределить значение одной из этих переменных по умолчанию, назначение игнорируется.
Примечание. Вы можете перечислить весь набор переменных среды, доступных для шага рабочего процесса, с помощью run: env
в шаге, а затем проверить вывод для шага.
Определение переменных конфигурации для нескольких рабочих процессов
Примечание. Переменные конфигурации для GitHub Actions находятся в beta и подлежат изменению.
Можно создавать переменные конфигурации для использования в нескольких рабочих процессах и определять их на уровне организации, репозитория или среды .
Например, можно использовать переменные конфигурации, чтобы задать значения по умолчанию для параметров, передаваемых в средства сборки на уровне организации, но затем разрешить владельцам репозитория переопределить эти параметры на основе регистра.
При определении переменных конфигурации они автоматически доступны в контексте vars
. Дополнительные сведения см. в разделе "Использование контекста для доступа к значениям vars
переменной конфигурации".
Приоритет переменной конфигурации
Если переменная с одинаковым именем существует на нескольких уровнях, переменная на самом низком уровне имеет приоритет. Например, если переменная уровня организации имеет то же имя, что и переменная уровня репозитория, то переменная уровня репозитория имеет приоритет. Аналогичным образом, если у организации, репозитория и среды есть переменная с одинаковым именем, переменная уровня среды имеет приоритет.
Для повторно используемых рабочих процессов используются переменные из репозитория вызывающего рабочего процесса. Переменные из репозитория, содержащего вызывающий рабочий процесс, недоступны для вызывающего рабочего процесса.
Соглашения об именовании для переменных конфигурации
Следующие правила применяются к именам переменных конфигурации:
Создание переменных конфигурации для репозитория
-
На GitHubперейдите на главную страницу репозитория.
-
Под именем репозитория щелкните Параметры. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и щелкните Параметры.
-
Перейдите на вкладку "Переменные".
-
Щелкните новую переменную репозитория.
-
В поле "Имя" введите имя переменной.
-
В поле "Значение" введите значение переменной.
-
Нажмите кнопку "Добавить переменную".
Создание переменных конфигурации для среды
Чтобы создать секреты или переменные для среды в репозитории личная учетная запись, необходимо быть владельцем репозитория. Чтобы создать секреты или переменные для среды в репозитории организации, необходимо иметь admin
доступ. Дополнительные сведения о средах см. в разделе "Управление средами для развертывания".
-
На GitHubперейдите на главную страницу репозитория.
-
Под именем репозитория щелкните Параметры. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и щелкните Параметры.
-
На левой боковой панели щелкните Среды.
-
Щелкните среду, в которую нужно добавить переменную.
-
В разделе переменные среды нажмите кнопку "Добавить переменную".
-
В поле "Имя" введите имя переменной.
-
В поле "Значение" введите значение переменной.
-
Нажмите кнопку "Добавить переменную".
Создание переменных конфигурации для организации
-
На GitHubперейдите на главную страницу организации.
-
Под именем организации щелкните Параметры. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и щелкните Параметры.
-
Перейдите на вкладку "Переменные".
- Щелкните "Создать переменную организации".
- В поле "Имя" введите имя переменной.
- В поле "Значение" введите значение переменной.
- В раскрывающемся списке Доступ к репозиторию выберите политику доступа.
- Нажмите кнопку "Добавить переменную".
Ограничения для переменных конфигурации
Отдельные переменные ограничены размером 48 КБ.
Вы можете хранить до 1000 переменных организации, 500 переменных на каждый репозиторий и 100 переменных на среду. Общее совокупное ограничение размера для переменных организации и репозитория составляет 10 МБ на выполнение рабочего процесса.
Рабочий процесс, созданный в репозитории, может получить доступ к следующему количеству переменных:
- До 500 переменных репозитория, если общий размер переменных репозитория меньше 10 МБ. Если общий размер переменных репозитория превышает 10 МБ, будут доступны только переменные репозитория, которые падают ниже предела (как отсортированные по алфавиту по имени переменной).
- До 1000 переменных организации, если общий совокупный размер переменных репозитория и организации меньше 10 МБ. Если общий совокупный размер переменных организации и репозитория превышает 10 МБ, будут доступны только переменные организации, которые падают ниже этого предела (после учета переменных репозитория и отсортированных по алфавиту по имени переменной).
- До 100 переменных уровня среды.
Примечание. Переменные уровня среды не учитываются в 10 МБ общего размера. Если превышено совокупное ограничение размера для переменных репозитория и организации и все еще требуется дополнительная переменная, можно использовать среду и определить дополнительные переменные в среде.
Использование контекстов для доступа к значениям переменных
Контексты — это способ доступа к сведениям о запусках рабочих процессов, переменных, средах выполнения, заданиях и шагах. Дополнительные сведения см. в разделе "Доступ к контекстной информации о запусках рабочих процессов". Существует множество других контекстов, которые можно использовать для различных целей в рабочих процессах. Дополнительные сведения о том, где можно использовать определенные контексты в рабочем процессе, см. в разделе "Доступ к контекстной информации о запусках рабочих процессов".
Доступ к значениям переменной среды можно получить с помощью значений контекста env
и переменных конфигурации с помощью контекста vars
.
Использование контекста для доступа к значениям переменной env
среды
Помимо переменных среды запуска GitHub Actions позволяет задавать и считывать env
значения ключей с помощью контекстов. Переменные среды и контексты предназначены для использования в разных точках рабочего процесса.
run
Шаги в рабочем процессе или в действии, на который ссылается ссылка, обрабатываются средством выполнения. В результате вы можете использовать переменные среды выполнения здесь, используя соответствующий синтаксис оболочки, используемой в средстве выполнения, например $NAME
оболочку Bash в средстве выполнения Linux или $env:NAME
PowerShell в средстве выполнения Windows. В большинстве случаев можно использовать контексты с синтаксисом ${{ CONTEXT.PROPERTY }}
, чтобы получить доступ к тому же значению. Разница заключается в том, что контекст будет интерполирован и заменен строкой перед отправкой задания в средство выполнения.
Однако нельзя использовать переменные среды runner в частях рабочего процесса, обрабатываемых GitHub Actions и не отправляются в средство выполнения. Вместо этого необходимо использовать контексты. Например, условный объект if
, определяющий, отправляется ли задание или шаг средству выполнения, всегда обрабатывается с помощью GitHub Actions. Поэтому для доступа к значению переменной необходимо использовать контекст в условном if
операторе.
name: Conditional env variable on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" if: ${{ env.DAY_OF_WEEK == 'Monday' }} run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
В этом изменении предыдущего примера мы ввели условный if
код. Теперь шаг рабочего процесса выполняется только в том случае, если для DAY_OF_WEEK
задано значение "Понедельник". Доступ к этому значению выполняется от условного оператора if
с помощью env
контекста. Контекст env
не требуется для переменных, на которые ссылается команда run
. Они ссылаются как на переменные среды runner и интерполируются после получения задания средством выполнения. Однако мы могли бы выполнить интерполяцию этих переменных перед отправкой задания в средство выполнения с помощью контекстов. Результирующий результат будет одинаковым.
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"
Примечание. Контексты обычно обозначаются с помощью знака доллара и фигурных скобок, в виде ${{ context.property }}
. В условном объекте if
${{
и }}
необязательны, но если вы их используете, они должны охватывать целый оператор сравнения, как показано выше.
Обычно используется либо env
github
контекст для доступа к значениям переменных в частях рабочего процесса, обрабатываемых перед отправкой заданий в средства выполнения.
Контекст | Вариант использования | Пример |
---|---|---|
env | Ссылка на пользовательские переменные, определенные в рабочем процессе. | ${{ env.MY_VARIABLE }} |
github | Справочная информация о запуске рабочего процесса и событии, которое инициировало запуск. | ${{ github.repository }} |
Предупреждение. Во время создания рабочих процессов и действий необходимо учитывать, будет ли код использовать непроверенные входные данные от возможных злоумышленников. Некоторые контексты следует считать непроверенными, так как злоумышленники могут вставить собственное вредоносное содержимое. Дополнительные сведения см. в разделе Защита системы безопасности для GitHub Actions.
Использование контекста vars
для доступа к значениям переменной конфигурации
Переменные конфигурации можно получить к рабочему процессу с помощью vars
контекста. Дополнительные сведения см. в разделе "Доступ к контекстной информации о запусках рабочих процессов".
Если переменная конфигурации не задана, возвращаемое значение контекста, ссылающееся на переменную, будет пустой строкой.
В следующем примере показано использование переменных конфигурации с контекстом vars
в рабочем процессе. Каждая из следующих переменных конфигурации определена на уровне репозитория, организации или среды.
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 }}
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 }}
Переменные среды по умолчанию
Переменные среды по умолчанию, которые устанавливает GitHub, доступны для каждого шага в рабочем процессе.
Поскольку переменные среды по умолчанию задаются GitHub и не определены в рабочем процессе, они недоступны через env
контекст. Однако большинство переменных по умолчанию имеют соответствующее и аналогично именованное свойство контекста. Например, значение переменной GITHUB_REF
можно считывать во время обработки рабочего процесса с помощью свойства контекста ${{ github.ref }}
.
Нельзя перезаписать значение переменных среды по умолчанию с именем GITHUB_*
и RUNNER_*
. В настоящее время можно перезаписать значение переменной CI
. Однако это не гарантируется, что это всегда будет возможно. Дополнительные сведения о настройке переменных среды см. в разделе "Определение переменных среды для одного рабочего процесса" и "Команды рабочего процесса для GitHub Actions".
Настоятельно рекомендуется использовать переменные для доступа к файловой системе, а не использовать жесткие пути к файлам. GitHub задает переменные для действий, используемых во всех средах выполнения.
«Переменная» | Description |
---|---|
CI | Всегда имеет значение true . |
GITHUB_ACTION | Имя выполняемого в настоящий момент действия или параметр id шага. Например, для действия — __repo-owner_name-of-action-repo .GitHub удаляет специальные символы и использует имя __run , когда в текущем шаге выполняется скрипт без параметра id . При использовании одного сценария или действия несколько раз в одном задании имя будет включать суффикс, состоящий из порядкового номера перед символом подчеркивания. Например, первый сценарий, который вы запустите, будет иметь имя __run , а второй сценарий будет называться __run_2 . Аналогично второй вызов actions/checkout будет называться actionscheckout2 . |
GITHUB_ACTION_PATH | Путь к расположению действия. Это свойство поддерживается только в составных действиях. Этот путь можно использовать для изменения каталогов, где находится действие, и получить доступ к другим файлам в том же репозитории. Например, /home/runner/work/_actions/repo-owner/name-of-action-repo/v1 . |
GITHUB_ACTION_REPOSITORY | Для шага, в котором выполняется действие, это имя владельца и репозитория, где находится действие. Например, actions/checkout . |
GITHUB_ACTIONS | Всегда имеет значение true , когда GitHub Actions запускает рабочий процесс. Эту переменную можно использовать, чтобы различать, когда тесты выполняются локально или с помощью GitHub Actions. |
GITHUB_ACTOR | Имя пользователя или приложения, инициирующего рабочий процесс. Например, octocat . |
GITHUB_ACTOR_ID | Идентификатор учетной записи пользователя или приложения, активировавшего начальное выполнение рабочего процесса. Например, 1234567 . Обратите внимание, что это отличается от имени пользователя субъекта. |
GITHUB_API_URL | Возвращает URL-адрес API. Например: http(s)://HOSTNAME/api/v3 . |
GITHUB_BASE_REF | Имя базовой ссылки или целевой ветки запроса на вытягивание в рабочем процессе. Это значение устанавливается только в том случае, если событием, запускающим рабочий процесс, является pull_request или pull_request_target . Например, main . |
GITHUB_ENV | Путь к файлу, который задает переменные из команд рабочего процесса. Путь к этому файлу является уникальным для текущего шага и изменения для каждого шага в задании. Например, /home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a . Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions. |
GITHUB_EVENT_NAME | Имя события, через которое был инициирован рабочий процесс. Например, workflow_dispatch . |
GITHUB_EVENT_PATH | В средстве выполнения это путь к файлу, в котором содержатся все полезные данные веб-перехватчика события. Например, /github/workflow/event.json . |
GITHUB_GRAPHQL_URL | Возвращает URL-адрес API GraphQL. Например: http(s)://HOSTNAME/api/graphql . |
GITHUB_HEAD_REF | Начальная ссылка или исходная ветвь запроса на вытягивание в рабочем процессе. Это свойство задается только в том случае, если событием, запускающим рабочий процесс, является pull_request или pull_request_target . Например, feature-branch-1 . |
GITHUB_JOB | job_id текущего задания. Например, greeting_job . |
GITHUB_OUTPUT | Путь к файлу, который задает выходные данные текущего шага из команд рабочих процессов. Путь к этому файлу является уникальным для текущего шага и изменения для каждого шага в задании. Например, /home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 . Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions. |
GITHUB_PATH | Путь средства выполнения к файлу, который устанавливает системные переменные PATH из команд рабочего процесса. Путь к этому файлу является уникальным для текущего шага и изменения для каждого шага в задании. Например, /home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 . Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions. |
GITHUB_REF | Полностью сформированный ссылку на ветвь или тег, активировавший выполнение рабочего процесса. Если рабочий процесс запущен по триггеру push , здесь указывается ссылка на отправленную ветвь или тег выпуска. Если рабочий процесс запущен по триггеру pull_request , здесь указывается ветвь слияния для запроса на вытягивание. Если рабочий процесс запущен по триггеру release , здесь указывается созданный тег выпуска. Для всех остальных триггеров указывается ссылка на ветвь или тег, которые активировали запуск рабочего процесса. Это значение задается только для тех типов событий, в которых доступны ветвь или тег. Ссылка сохраняется в полном формате, то есть refs/heads/<branch_name> для ветвей, refs/pull/<pr_number>/merge для запросов на вытягивание и refs/tags/<tag_name> для тегов. Например, refs/heads/feature-branch-1 . |
GITHUB_REF_NAME | Короткое имя ссылки ветви или тега, активировав выполнение рабочего процесса. Это значение соответствует имени ветви или тега, отображаемого на GitHub. Например, feature-branch-1 .Для запросов на вытягивание используется <pr_number>/merge формат. |
GITHUB_REF_PROTECTED | true Значение , если защита ветви настроены для ссылки, которая активировала выполнение рабочего процесса. |
GITHUB_REF_TYPE | Тип ссылки, активировавшей выполнение рабочего процесса. Допустимые значения — branch или tag . |
GITHUB_REPOSITORY | Имя владельца и репозитория. Например, octocat/Hello-World . |
GITHUB_REPOSITORY_ID | Идентификатор репозитория. Например, 123456789 . Обратите внимание, что это отличается от имени репозитория. |
GITHUB_REPOSITORY_OWNER | Имя владельца репозитория. Например, octocat . |
GITHUB_REPOSITORY_OWNER_ID | Идентификатор учетной записи владельца репозитория. Например, 1234567 . Обратите внимание, что это отличается от имени владельца. |
GITHUB_RETENTION_DAYS | Количество дней, в течение которых рабочий процесс выполняет журналы и артефакты. Например, 90 . |
GITHUB_RUN_ATTEMPT | Уникальное число для каждой попытки конкретного рабочего процесса, выполняемого в репозитории. Первая попытка обозначается номером 1, для всех последующих номер увеличивается. Например, 3 . |
GITHUB_RUN_ID | Уникальный номер каждого запуска рабочего процесса в репозитории. Он не изменяется при повторном запуске рабочего процесса. Например, 1658821493 . |
GITHUB_RUN_NUMBER | Уникальный номер для каждого запуска определенного рабочего процесса в репозитории. Он начинается с цифры 1 для первого запуска рабочего процесса и увеличивается с каждым новым запуском. Он не изменяется при повторном запуске рабочего процесса. Например, 3 . |
GITHUB_SERVER_URL | URL-адрес сервера GitHub Enterprise Server . Например: https://HOSTNAME . |
GITHUB_SHA | SHA фиксации, инициировавшей рабочий процесс. Значение этой фиксации SHA зависит от события, активирующего рабочий процесс. Дополнительные сведения см. в разделе События, инициирующие рабочие процессы. Например, ffac537e6cbbf934b08745a378932722df287a53 . |
GITHUB_STEP_SUMMARY | Путь к файлу, который содержит сводки заданий из команд рабочего процесса. Путь к этому файлу является уникальным для текущего шага и изменения для каждого шага в задании. Например, /home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c . Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions. |
GITHUB_TRIGGERING_ACTOR | Имя пользователя, запустившего экземпляр рабочего процесса. Если рабочий процесс выполняется повторно, это значение может отличаться от github.actor . В повторных запусках рабочих процессов будут использоваться привилегии github.actor , даже если субъект, инициировавший повторный запуск (github.triggering_actor ), имеет другие привилегии. |
GITHUB_WORKFLOW | Имя рабочего процесса. Например, My test workflow . Если в файле рабочего процесса не указано свойство name , значением этой переменной является полный путь к файлу рабочего процесса в репозитории. |
GITHUB_WORKFLOW_REF | Путь ссылки к рабочему процессу. Например, octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch . |
GITHUB_WORKFLOW_SHA | Фиксация SHA для файла рабочего процесса. |
GITHUB_WORKSPACE | Рабочий каталог по умолчанию в средстве выполнения для шагов и расположение по умолчанию репозитория при использовании checkout действия. Например, /home/runner/work/my-repo-name/my-repo-name . |
RUNNER_ARCH | Архитектура средства выполнения задания. Возможные значения: X86 , X64 , ARM или ARM64 . |
RUNNER_DEBUG | Это делается только в том случае, если ведение журнала отладки включено и всегда имеет значение 1 . Это может быть полезно в качестве индикатора для включения дополнительной отладки или подробного ведения журнала в ваших шагах задания. |
RUNNER_ENVIRONMENT | Среда выполнения задания. Возможные значения: github-hosted для управляемых GitHub средств выполнения, предоставляемых GitHub, а self-hosted также для локальных модулей выполнения, настроенных владельцем репозитория. |
RUNNER_NAME | Имя средства выполнения задания. Это имя может не быть уникальным в рабочем процессе, выполняемом в качестве средств выполнения на уровне репозитория и организации, может использовать то же имя. Например Hosted Agent |
RUNNER_OS | Операционная система средства выполнения тестов, выполняющего задание. Возможные значения: Linux , Windows или macOS . Например Windows |
RUNNER_TEMP | Путь к временному каталогу в средстве выполнения. Этот каталог очищается в начале и конце каждого задания. Обратите внимание, что файлы не удаляются, если у учетной записи пользователя средства выполнения нет разрешения на их удаление. Например D:\a\_temp |
RUNNER_TOOL_CACHE | Путь к каталогу, содержащему предустановленные средства для размещенных в GitHub средств выполнения. Дополнительные сведения см. в разделе "Использование средств выполнения, размещенных в GitHub". Например C:\hostedtoolcache\windows |
Примечание. Если необходимо использовать URL-адрес запуска рабочего процесса из задания, можно объединить следующие переменные: $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
Обнаружение операционной системы
Вы можете написать один файл рабочего процесса, который можно использовать для разных операционных систем, используя переменную среды по умолчанию RUNNER_OS
и соответствующее свойство контекста ${{ runner.os }}
. Например, следующий рабочий процесс может быть успешно запущен, если вы изменили операционную систему с macos-latest
на windows-latest
без необходимости изменять синтаксис переменных среды, который различается в зависимости от оболочки, используемой средством выполнения.
on: workflow_dispatch jobs: if-Windows-else: runs-on: macos-latest steps: - name: condition 1 if: runner.os == 'Windows' run: echo "The operating system on the runner is $env:RUNNER_OS." - name: condition 2 if: runner.os != 'Windows' run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
on: workflow_dispatch
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
В этом примере два оператора if
проверяют свойство os
контекста runner
, чтобы определить операционную систему средства выполнения. Условные объекты if
обрабатываются с помощью GitHub Actions, и средству выполнения отправляются только те шаги, для которых проверка разрешается в виде true
. Здесь одна из проверок всегда будет иметь значение true
, а другая — false
, поэтому только один из этих шагов отправляется в средство выполнения. После отправки задания в средство выполнения выполняется шаг, а переменная среды в echo
команде интерполируется с помощью соответствующего синтаксиса ($env:NAME
для PowerShell в Windows, а $NAME
также для bash и sh в Linux и macOS). В этом примере оператор runs-on: macos-latest
означает, что будет выполняться второй шаг.
Передача значений между шагами и заданиями в рабочем процессе
Если вы создаете значение в одном шаге задания, его можно использовать в последующих шагах того же задания, назначив значение существующей или новой переменной среды, а затем записав это значение в файл среды GITHUB_ENV
. Файл среды может использоваться непосредственно действием или командой оболочкой в файле рабочего процесса с помощью ключевого слова run
. Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions.
Если вы хотите передать значение из шага одного задания в рабочем процессе в шаг другого задания в рабочем процессе, можно определить значение как вывод задания. Затем вы можете ссылаться на этот вывод задания из шага другого задания. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.