Хранение сведений в переменных

Определение переменных среды для одного рабочего процесса

Чтобы задать настраиваемую переменную среды для одного рабочего процесса, ее можно определить с помощью env ключа в файле рабочего процесса. Область настраиваемой переменной, заданной этим методом, ограничена элементом, в котором она определена. Можно определить переменные, для которых задана область:

Весь рабочий процесс с использованием env на верхнем уровне файла рабочего процесса.
Содержимое задания в рабочем процессе с использованием jobs.<job_id>.env.
Определенный шаг задания с использованием jobs.<job_id>.steps[*].env.

YAML

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.

Определение переменных конфигурации для нескольких рабочих процессов

Можно создавать переменные конфигурации для использования в нескольких рабочих процессах и определять их на уровне организации, репозитория или среды .

Например, можно использовать переменные конфигурации, чтобы задать значения по умолчанию для параметров, передаваемых в средства сборки на уровне организации, но затем разрешить владельцам репозитория переопределить эти параметры на основе регистра.

При определении переменных конфигурации они автоматически доступны в контексте vars . Дополнительные сведения см. в разделе "Использование контекста vars для доступа к значениям переменной конфигурации".

Создание переменных конфигурации для репозитория

На GitHubперейдите на главную страницу репозитория.
Под именем репозитория щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".
Перейдите на вкладку "Переменные".
Щелкните новую переменную репозитория.
В поле "Имя" введите имя переменной.
В поле "Значение" введите значение переменной.
Нажмите кнопку "Добавить переменную".

Создание переменных конфигурации для среды

Чтобы создать секреты или переменные для среды в репозитории личная учетная запись, необходимо быть владельцем репозитория. Чтобы создать секреты или переменные для среды в репозитории организации, необходимо иметь admin доступ. Дополнительные сведения о средах см. в разделе Управление средами для развертывания.

На GitHubперейдите на главную страницу репозитория.
Под именем репозитория щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".
На левой боковой панели щелкните Среды.
Щелкните среду, в которую нужно добавить переменную.
В разделе переменные среды нажмите кнопку "Добавить переменную".
В поле "Имя" введите имя переменной.
В поле "Значение" введите значение переменной.
Нажмите кнопку "Добавить переменную".

Создание переменных конфигурации для организации

На GitHubперейдите на главную страницу организации.
Под именем организации щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".
Перейдите на вкладку "Переменные".

Снимок экрана: страница "Секреты действий и переменные". Вкладка "Переменные" выделена темно-оранжевым цветом.

Щелкните "Создать переменную организации".
В поле "Имя" введите имя переменной.
В поле "Значение" введите значение переменной.
В раскрывающемся списке Доступ к репозиторию выберите политику доступа.
Нажмите кнопку "Добавить переменную".

Использование контекстов для доступа к значениям переменных

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

Доступ к значениям переменной среды можно получить с помощью значений контекста env и переменных конфигурации с помощью контекста vars .

Использование контекста для доступа к значениям переменной `env` среды

Помимо переменных среды запуска GitHub Actions позволяет задавать и считывать env значения ключей с помощью контекстов. Переменные среды и контексты предназначены для использования в разных точках рабочего процесса.

run Шаги в рабочем процессе или в действии, на который ссылается ссылка, обрабатываются средством выполнения. В результате вы можете использовать переменные среды выполнения здесь, используя соответствующий синтаксис оболочки, используемой в средстве выполнения, например $NAME оболочку Bash в средстве выполнения Linux или $env:NAME PowerShell в средстве выполнения Windows. В большинстве случаев можно использовать контексты с синтаксисом ${{ CONTEXT.PROPERTY }}, чтобы получить доступ к тому же значению. Разница заключается в том, что контекст будет интерполирован и заменен строкой перед отправкой задания в средство выполнения.

Однако нельзя использовать переменные среды runner в частях рабочего процесса, обрабатываемых GitHub Actions и не отправляются в средство выполнения. Вместо этого необходимо использовать контексты. Например, условный объект if, определяющий, отправляется ли задание или шаг средству выполнения, всегда обрабатывается с помощью GitHub Actions. Поэтому для доступа к значению переменной необходимо использовать контекст в условном if операторе.

YAML

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 ${{ и }} необязательны, но если вы их используете, они должны охватывать целый оператор сравнения, как показано выше.

Предупреждение

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

Использование контекста `vars` для доступа к значениям переменной конфигурации

Переменные конфигурации можно получить к рабочему процессу с помощью vars контекста. Дополнительные сведения см. в разделе Справочник по контекстам.

Если переменная конфигурации не задана, возвращаемое значение контекста, ссылающееся на переменную, будет пустой строкой.

В следующем примере показано использование переменных конфигурации с контекстом vars в рабочем процессе. Каждая из следующих переменных конфигурации определена на уровне репозитория, организации или среды.

YAML

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 }}

Обнаружение операционной системы

Вы можете написать один файл рабочего процесса, который можно использовать для разных операционных систем, используя переменную среды по умолчанию RUNNER_OS и соответствующее свойство контекста ${{ runner.os }}. Например, следующий рабочий процесс может быть успешно запущен, если вы изменили операционную систему с macos-latest на windows-latest без необходимости изменять синтаксис переменных среды, который различается в зависимости от оболочки, используемой средством выполнения.

YAML

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.

Следующие шаги

Справочные сведения см. в разделе Справочник по переменным.

Хранение сведений в переменных

В этой статье