# Хранение сведений в переменных GitHub задает переменные по умолчанию для каждого GitHub Actions запуска рабочего процесса. Можно также задать пользовательские переменные для использования в одном рабочем процессе или нескольких рабочих процессах. ## Определение переменных среды для одного рабочего процесса Чтобы задать настраиваемую переменную среды для одного рабочего процесса, ее можно определить с помощью `env` ключа в файле рабочего процесса. Область настраиваемой переменной, заданной этим методом, ограничена элементом, в котором она определена. Можно определить переменные, для которых задана область: * Весь рабочий процесс с использованием [`env`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env) на верхнем уровне файла рабочего процесса. * Содержимое задания в рабочем процессе с использованием [`jobs..env`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idenv). * Определенный шаг задания с использованием [`jobs..steps[*].env`](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsenv). ```yaml copy 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` шагах, но в частях рабочего процесса, которые не отправляются в средство выполнения, необходимо использовать контексты для доступа к значениям переменных. Дополнительные сведения см. в разделе ["Использование контекстов для доступа к значениям](#using-contexts-to-access-variable-values) переменных". Так как интерполяция переменной среды выполнения выполняется после отправки задания рабочего процесса на компьютер runner, необходимо использовать соответствующий синтаксис для оболочки, используемой в средстве выполнения. В этом примере рабочим процессом указано `ubuntu-latest`. По умолчанию средства выполнения Linux используют оболочку Bash, поэтому необходимо использовать синтаксис `$NAME`. По умолчанию средства выполнения Windows используют PowerShell, поэтому вы будете использовать синтаксис `$env:NAME`. Дополнительные сведения о оболочках см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell). ## Определение переменных конфигурации для нескольких рабочих процессов Можно создавать переменные конфигурации для использования в нескольких рабочих процессах и определять их на [уровне организации](#creating-configuration-variables-for-an-organization), [репозитория](#creating-configuration-variables-for-a-repository) или [среды](#creating-configuration-variables-for-an-environment) . Например, можно использовать переменные конфигурации, чтобы задать значения по умолчанию для параметров, передаваемых в средства сборки на уровне организации, но затем разрешить владельцам репозитория переопределить эти параметры на основе регистра. При определении переменных конфигурации они автоматически доступны в контексте `vars` . Дополнительные сведения см. в разделе ["Использование контекста `vars` для доступа к значениям](#using-the-vars-context-to-access-configuration-variable-values) переменной конфигурации". ### Создание переменных конфигурации для репозитория Чтобы создать секреты или переменные на GitHub для репозитория организации, необходимо иметь `write` доступ. Для репозитория личной учетной записи вы должны быть соавтором репозитория. 1. На GitHubперейдите на главную страницу репозитория. 2. Под именем репозитория щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**". ![Снимок экрана: заголовок репозитория с вкладками. Вкладка "Параметры" выделена темно-оранжевым контуром.](/assets/images/help/repository/repo-actions-settings.png) 3. В разделе "Безопасность" боковой панели выберите ** Секреты и переменные**, а затем нажмите кнопку **"Действия**". 4. Перейдите на вкладку **"Переменные".** ![Скриншот страницы «Действия, секреты и переменные». Вкладка "Переменные" выделена темно-оранжевым цветом.](/assets/images/help/repository/actions-variables-tab.png) 1. Щелкните **новую переменную** репозитория. 2. **В поле "Имя"** введите имя переменной. 3. **В поле "Значение"** введите значение переменной. 4. Нажмите кнопку **"Добавить переменную**". ### Создание переменных конфигурации для среды Чтобы создать секреты или переменные для среды в репозитории личная учетная запись, необходимо быть владельцем репозитория. Чтобы создать секреты или переменные для среды в репозитории организации, необходимо иметь `admin` доступ. Дополнительные сведения о средах см. в разделе [Управление средами для развертывания](/ru/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). 1. На GitHubперейдите на главную страницу репозитория. 2. Под именем репозитория щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**". ![Снимок экрана: заголовок репозитория с вкладками. Вкладка "Параметры" выделена темно-оранжевым контуром.](/assets/images/help/repository/repo-actions-settings.png) 3. На левой боковой панели щелкните **Среды**. 4. Щелкните среду, в которую нужно добавить переменную. 5. В разделе **переменные среды нажмите кнопку **"Добавить переменную****". 6. **В поле "Имя"** введите имя переменной. 7. **В поле "Значение"** введите значение переменной. 8. Нажмите кнопку **"Добавить переменную**". ### Создание переменных конфигурации для организации При создании секрета или переменной в организации можно использовать политику для ограничения доступа к репозиторию. Например, можно предоставить доступ ко всем репозиториям либо ограничить доступ только частными репозиториями или указанным списком репозиториев. Владельцы и пользователи организации с разрешениями "Управление переменными действий организации" или "Управление секретами действий организации" могут создавать секреты или переменные на уровне организации. Для получения дополнительной информации см. [Разрешения на кастомные организационные роли](/ru/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles). 1. На GitHubперейдите на главную страницу организации. 2. Под именем организации щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**". ![Снимок экрана: вкладки в профиле организации. Вкладка "Параметры" выделена темно-оранжевым цветом.](/assets/images/help/discussions/org-settings-global-nav-update.png) 3. В разделе "Безопасность" боковой панели выберите ** Секреты и переменные**, а затем нажмите кнопку **"Действия**". 4. Перейдите на вкладку **"Переменные".** ![Снимок экрана: страница "Секреты действий и переменные". Вкладка "Переменные" выделена темно-оранжевым цветом.](/assets/images/help/repository/actions-variables-tab.png) > \[!NOTE] > На странице "Действия секреты и переменные" могут не отображаться отдельные вкладки секретов и переменных в зависимости от разрешений. Владельцы и пользователи организации с разрешениями "Управление переменными действий организации" и "Управление секретами действий организации" будут отображать **вкладки "Переменные** и **секреты** ". Дополнительные сведения см. в разделе [Разрешения на кастомные организационные роли](/ru/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles). 5. Щелкните **"Создать переменную** организации". 6. **В поле "Имя"** введите имя переменной. 7. **В поле "Значение"** введите значение переменной. 8. В раскрывающемся списке **Доступ к репозиторию** выберите политику доступа. 9. Нажмите кнопку **"Добавить переменную**". ## Использование контекстов для доступа к значениям переменных Контексты — это способ доступа к сведениям о запусках рабочих процессов, переменных, средах выполнения, заданиях и шагах. Для получения дополнительной информации см. [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts). Существует множество других контекстов, которые можно использовать для различных целей в рабочих процессах. Дополнительные сведения о том, где можно использовать определенные контексты в рабочем процессе, см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). Доступ к значениям переменной среды можно получить с помощью значений контекста `env` и переменных конфигурации с помощью контекста `vars` . ### Использование контекста для доступа к значениям переменной `env` среды Помимо переменных среды выполнения, GitHub Actions можно задать и считывать `env` значения ключей с помощью контекстов. Переменные среды и контексты предназначены для использования в разных точках рабочего процесса. `run` Шаги в рабочем процессе или в действии, на который ссылается ссылка, обрабатываются средством выполнения. В результате вы можете использовать переменные среды выполнения здесь, используя соответствующий синтаксис оболочки, используемой в средстве выполнения, например `$NAME` оболочку Bash в средстве выполнения Linux или `$env:NAME` PowerShell в средстве выполнения Windows. В большинстве случаев можно также использовать контексты с синтаксисом `${{ CONTEXT.PROPERTY }}`для доступа к одному значению. Разница заключается в том, что контекст будет интерполирован и заменен строкой перед отправкой задания в средство выполнения. Однако переменные среды выполнения нельзя использовать в частях рабочего процесса, обрабатываемых GitHub Actions и не отправляемых в средство выполнения. Вместо этого необходимо использовать контексты. Например, условный объект, определяющий `if` , отправляется ли задание или шаг в средство выполнения, всегда обрабатывается GitHub Actions. Поэтому для доступа к значению переменной необходимо использовать контекст в `if` условном операторе. ```yaml copy 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` контекста](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#env-context). Контекст `env` не требуется для переменных, на которые ссылается команда `run` . Они ссылаются как на переменные среды runner и интерполируются после получения задания средством выполнения. Однако мы могли бы выполнить интерполяцию этих переменных перед отправкой задания в средство выполнения с помощью контекстов. Результирующий результат будет одинаковым. ```yaml run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" ``` > \[!NOTE] > Контексты обычно указываются с помощью знака доллара и фигурных скобок, как `${{ context.property }}`. В условном `if` виде `${{` и `}}` являются необязательными, но если они используются, они должны заключать весь оператор сравнения, как показано выше. > \[!WARNING] > При создании рабочих процессов и действий следует всегда учитывать, может ли код выполнять ненадежные входные данные от возможных злоумышленников. Некоторые контексты следует считать непроверенными, так как злоумышленники могут вставить собственное вредоносное содержимое. Дополнительные сведения см. в разделе [Справочник по безопасному использованию](/ru/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks). ### Использование контекста `vars` для доступа к значениям переменной конфигурации Переменные конфигурации можно получить к рабочему процессу с помощью `vars` контекста. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context). Если переменная конфигурации не задана, возвращаемое значение контекста, ссылающееся на переменную, будет пустой строкой. В следующем примере показано использование переменных конфигурации с контекстом `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 }} ``` ## Обнаружение операционной системы Можно написать один файл рабочего процесса, который можно использовать для разных операционных систем, используя `RUNNER_OS` переменную среды по умолчанию и соответствующее свойство `${{ runner.os }}`контекста. Например, следующий рабочий процесс может быть успешно запущен, если вы изменили операционную систему с `macos-latest` на `windows-latest` без необходимости изменять синтаксис переменных среды, который различается в зависимости от оболочки, используемой средством выполнения. ```yaml copy 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](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable). Если вы хотите передать значение из шага одного задания в рабочем процессе в шаг другого задания в рабочем процессе, можно определить значение как вывод задания. Затем вы можете ссылаться на этот вывод задания из шага другого задания. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs). ## Следующие шаги Справочные сведения см. в разделе [Справочник по переменным](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/variables).