关于变量
变量提供了一种存储和重用非敏感配置信息的方法。 可以将任何配置数据(如编译器标志、用户名或服务器名称)存储为变量。 变量在运行工作流的运行器计算机上插值。 在操作或工作流步骤中运行的命令可以创建、读取和修改变量。
可以设置自己的自定义变量,也可以使用 GitHub 自动设置的默认环境变量。 有关详细信息,请参阅“ 默认环境变量 ”。
可以通过两种方式设置自定义变量。
env
键。 有关详细信息,请参阅“
为单个工作流定义环境变量
”。
Warning
默认情况下,变量在生成输出中未经屏蔽地呈现。 如果需要提高敏感信息(如密码)的安全性,请改用机密。 有关详细信息,请参阅“ 在 GitHub Actions 中使用机密 ”。
为单个工作流定义环境变量
若要设置单个工作流的自定义环境变量,可以在工作流文件中使用
env
键进行定义。 此方法设置的自定义变量的作用域仅限于在其中定义它的元素。 可以定义作用域如下的变量:
env
。
jobs.<job_id>.env
。
jobs.<job_id>.steps[*].env
。
name: Greeting on variable day workflow_dispatch DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" First_Name: Mona
name: Greeting on variable day
workflow_dispatch
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
First_Name: Mona
可以使用运行器环境变量或上下文访问 env
变量值。 上面的示例显示了要在 echo
命令中用作运行器环境变量的 3 个自定义变量:$DAY_OF_WEEK
、$Greeting
和 $First_Name
。 这些变量的值分别在工作流、作业和步骤级别设置和定义作用域。 这些变量的内插发生在运行器上。
工作流或引用操作 run
步骤中的命令由在运行器上使用的 shell 处理。 工作流其他部件中的指令由 GitHub Actions 处理,不会发送到运行器。 可以在 run
步骤中使用运行器环境变量或上下文,但在未发送到运行器的工作流部件中,必须使用上下文来访问变量值。 有关详细信息,请参阅“使用上下文访问变量值”。
由于运行器环境变量插值是在将工作流作业发送到运行器计算机后完成的,因此必须对运行器上使用的 shell 使用适当的语法。 在此示例中,工作流指定 ubuntu-latest
。 默认情况下,Linux 运行器使用 bash shell,因此你需要使用语法 $NAME
。 Windows 运行器默认使用 PowerShell,因此您将使用语法 $env:NAME
。 有关 shell 的详细信息,请参阅“GitHub Actions 的工作流语法”。
环境变量命名约定
设置环境变量时,不能使用任何默认环境变量名称。 有关默认环境变量的完整列表,请参阅下面的“默认环境变量”。 如果尝试重写其中一个默认变量的值,则会忽略赋值。
通过在步骤中使用 run: env
并检查此步骤的输出,可以列出可用于工作流步骤的整个环境变量集。
为多个工作流定义配置变量
GitHub Actions 的配置变量为 公共预览版,可能随时更改。
可以创建用于多个工作流的配置变量,并且可以在组织、存储库或环境级别定义它们。
例如,可以使用配置变量为传递给组织级别的生成工具的参数设置默认值,但随后允许存储库所有者根据具体情况重写这些参数。
定义配置变量时,它们在 vars
上下文中自动可用。 有关详细信息,请参阅“使用 vars
上下文访问配置变量值”。
配置变量优先级
如果具有相同名称的变量存在于多个级别,则级别最低的变量优先。 例如,如果组织级别变量的名称与存储库级别的变量相同,则存储库级别的变量优先。 同样,如果组织、存储库和环境都具有同名的变量,则环境级变量优先。
对于可重用工作流,将使用调用方工作流存储库中的变量。 存储库中包含被调用工作流的变量不可用于调用方工作流。
配置变量的命名约定
以下规则适用于配置变量名称:
名称只能包含字母数字字符([a-z]
、[A-Z]
、[0-9]
)或下划线 (_
)。 不允许空格。
名称不能以 GITHUB_
前缀开头。
名称不能以数字开头。
名称不区分大小写。
名称在所创建的级别上必须是唯一的。
为存储库创建配置变量
若要在 GitHub 上为个人帐户存储库创建机密或变量,你必须是存储库所有者。 若要在 GitHub 上为组织存储库创建机密或变量,你必须拥有 admin
访问权限。 最后,若要通过 REST API 为个人帐户存储库或组织存储库创建机密或变量,你必须拥有协作者访问权限。
在 GitHub 上,导航到存储库的主页面。
在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”。
在边栏的“安全性”部分中,选择 机密和变量,然后单击 操作。
单击“变量”选项卡。
单击“新建存储库变量”。
在“名称”字段中输入变量的名称。
在“值”字段中输入变量的值。
单击“添加变量”。
为环境创建配置变量
要为个人帐户存储库中的环境创建密码或变量,你必须是存储库所有者。 要为组织存储库中的环境创建密码或变量,必须具有 admin
访问权限。 有关环境的详细信息,请参阅“管理部署环境”。
在 GitHub 上,导航到存储库的主页面。
在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”。
在左侧边栏中,单击“环境”。
单击要向其添加变量的环境。
在“环境变量”下,单击“添加变量”。
在“名称”字段中输入变量的名称。
在“值”字段中输入变量的值。
单击“添加变量”。
为组织创建配置变量
GitHub Free 的专用存储库无法访问组织级机密和变量。 有关升级 GitHub 订阅的详细信息,请参阅“升级帐户的计划”。
在组织中创建机密或变量时,可以使用策略来限制存储库的访问。 例如,您可以将访问权限授予所有仓库,也可以限制仅私有仓库或指定的仓库列表拥有访问权限。
组织所有者可以在组织级别创建机密或变量。
在 GitHub 上,导航到组织的主页面。
在组织名称下,单击 “设置”****。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”********。
在边栏的“安全性”部分中,选择 机密和变量,然后单击 操作。
单击“变量”选项卡。
单击“新建组织变量”。
在“名称”字段中输入变量的名称。
在“值”字段中输入变量的值。
从“存储库访问”下拉列表中,选择访问策略。
单击“添加变量”。
配置变量的限制
单个变量大小限制为 48 KB。
最多可以存储 1,000 个组织变量、每个存储库 500 个变量和每个环境 100 个变量。 组织和存储库变量的总大小限制为每个工作流运行 256 KB。
在存储库中创建的工作流可以访问以下数量的变量:
如果存储库变量的总大小小于 256 KB,则最多 500 个存储库变量。 如果存储库变量的总大小超过 256 KB,则只有低于限制的存储库变量才可用(按变量名称的字母顺序排序)。
如果存储库和组织变量的总大小小于 256 KB,则最多 1,000 个组织变量。 如果组织和存储库变量的总大小超过 256 KB,则只有低于该限制的组织变量将可用(在考虑存储库变量并按变量名称的字母顺序排序后)。
最多 100 个环境级别变量。
环境级别变量不计入 256 KB 的总大小限制。 如果超出了存储库和组织变量的总大小限制,但仍需要其他变量,则可以使用一个环境并在该环境中定义其他变量。
使用上下文访问变量值
上下文是一种访问工作流运行、变量、运行器环境、作业及步骤相关信息的方式。 有关详细信息,请参阅“访问有关工作流运行的上下文信息”。 在工作流程中,还有许多其他上下文可用于各种目的。 有关可在工作流中使用特定上下文的位置的详细信息,请参阅“访问有关工作流运行的上下文信息”。
可以使用 env
上下文来访问环境变量值,还可以使用 vars
上下文来访问配置变量值。
使用 env
上下文访问环境变量值
除了运行器环境变量之外,GitHub Actions 还允许使用上下文设置和读取 env
键值。 环境变量和上下文旨在用于工作流程中的不同点。
工作流或引用操作中的 run
步骤由运行器处理。 因此,可以使用此处的运行器环境变量,对运行器上使用的 shell 使用适当的语法(例如,Linux 运行器上的 bash shell 使用 $NAME
,Windows 运行器上的 PowerShell 使用 $env:NAME
)。 在大多数情况下,还可以使用语法为 ${{ CONTEXT.PROPERTY }}
的上下文来访问相同的值。 区别在于,在作业发送到运行器之前,上下文将被内插并替换为字符串。
但是,在由 GitHub Actions 处理且不会发送到运行器的工作流部件中,无法使用运行器环境变量。 相反,您必须使用上下文。 例如,if
条件(用于确定作业或步骤是否发送到运行器)始终由 GitHub Actions 处理。 必须在 if
条件语句中使用上下文访问变量的值。
YAMLname: Conditional env variable
on: workflow_dispatch
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
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!"
First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
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!"
First_Name: Mona
在前面的示例的此修改中,我们引入了 if
条件。 工作流步骤现在仅当 DAY_OF_WEEK
设置为“Monday”时才运行。 我们使用 env
上下文从 if
条件语句中访问此值。 run
命令中引用的变量不需要 env
上下文。 这些变量被引用为运行器环境变量,并在运行器收到作业后进行内插。 不过,可以选择在将作业发送到运行器之前,通过使用上下文内插这些变量。 输出结果相同。
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 }}
Warning
创建工作流和操作时,应始终考虑代码是否可能执行潜在攻击者的不受信任的输入。 某些上下文应被视为不受信任的输入,因为攻击者可能会插入自己的恶意内容。 有关详细信息,请参阅“GitHub Actions 的安全强化”。
使用 vars
上下文访问配置变量值
可以使用 vars
上下文在整个工作流中访问配置变量。 有关详细信息,请参阅“访问有关工作流运行的上下文信息”。
如果尚未设置配置变量,则引用该变量的上下文的返回值将为空字符串。
以下示例演示如何在工作流中将配置变量与 vars
上下文配合使用。 以下每个配置变量都已在存储库、组织或环境级别上定义。
YAMLon:
workflow_dispatch:
# 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"
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 }}
workflow_dispatch:
# 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"
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 设置供操作用于所有运行器环境中的变量。
变量 说明 CI
始终设置为 true
。 GITHUB_ACTION
正在运行的操作的名称,或步骤的 id
。 例如,对于操作,为 __repo-owner_name-of-action-repo
。
在当前步骤运行不带 id
的脚本时,GitHub 会删除特殊字符并使用名称 __run
。 如果在同一作业中多次使用相同的脚本或操作,则名称将包含一个由序号前跟下划线组成的后缀。 例如,运行的第一个脚本的名称将为 __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
当 GitHub Actions 运行工作流时,始终设置为 true
。 您可以使用此变量来区分测试是在本地运行还是通过 GitHub Actions 运行。 GITHUB_ACTOR
发起工作流程的个人或应用程序的名称。 例如,octocat
。 GITHUB_ACTOR_ID
触发初始工作流运行的个人或应用的帐户 ID。 例如 1234567
。 请注意,这与参与者用户名不同。 GITHUB_API_URL
返回 API URL。 例如:https://api.github.com
。 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
运行器上包含完整事件 web 挂钩负载的文件的路径。 例如 /github/workflow/event.json
。 GITHUB_GRAPHQL_URL
返回 GraphQL API URL。 例如:https://api.github.com/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
如果为触发工作流运行的 ref 配置分支保护 或 规则集 ,则为 true
。 GITHUB_REF_TYPE
触发工作流运行的 ref 类型。 有效值为 branch
or tag
进行求值的基于 SQL 语言的筛选器表达式。 GITHUB_REPOSITORY
所有者和仓库名称。 例如,octocat/Hello-World
。 GITHUB_REPOSITORY_ID
存储库的 ID。 例如 123456789
。 请注意,这与存储库名称不同。 GITHUB_REPOSITORY_OWNER
存储库所有者的名称。 例如,octocat
。 GITHUB_REPOSITORY_OWNER_ID
存储库所有者的帐户 ID。 例如 1234567
。 请注意,这与所有者名称不同。 GITHUB_RETENTION_DAYS
工作流运行日志和项目保留的天数。 例如,90
。 GITHUB_RUN_ATTEMPT
存储库中每次尝试运行特定工作流的唯一编号。 对于工作流程运行的第一次尝试,此数字从 1 开始,并随着每次重新运行而递增。 例如,3
。 GITHUB_RUN_ID
存储库中每个工作流运行的唯一编号。 如果您重新执行工作流程运行,此编号不变。 例如 1658821493
。 GITHUB_RUN_NUMBER
仓库中特定工作流程每个运行的唯一编号。 工作流首次运行时,此编号从 1 开始,并随着每次新的运行而递增。 如果您重新执行工作流程运行,此编号不变。 例如 3
。 GITHUB_SERVER_URL
GitHub 服务器的 URL。 例如:https://github.com
。 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.triggering_actor
) 具有不同的权限,任何工作流重新运行都将使用 github.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 提供的 GitHub 托管的运行器为 github-hosted
,对于存储库所有者配置的自承载运行器为 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
,以下工作流可以成功运行,而不必更改环境变量的语法,这会根据运行器使用的 shell 而有所不同。
YAMLon: 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'