From cf7a4bba0011c4f15e8a25a1a6a1cd8763da524a Mon Sep 17 00:00:00 2001 From: "Kayla Reopelle (she/her)" <87386821+kaylareopelle@users.noreply.github.com> Date: Wed, 12 Jul 2023 12:26:13 -0700 Subject: [PATCH 1/9] Update example to use env. within expression The example as-is did not work for me on ubuntu-latest. This syntax worked. I received an "Invalid workflow file" error. --- content/actions/learn-github-actions/variables.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index b0d756124bd4..102119ebb540 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -69,16 +69,16 @@ jobs: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" - run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" + run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" env: First_Name: Mona ``` {% endraw %} -You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." +You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as environment variables in an `echo` command: `env.DAY_OF_WEEK`, `env.Greeting`, and `env.First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." -Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." +Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `env.NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." ### Naming conventions for environment variables From 5207ef0a164af23eaa2eefca5e365dcdbc6328d8 Mon Sep 17 00:00:00 2001 From: "Kayla Reopelle (she/her)" <87386821+kaylareopelle@users.noreply.github.com> Date: Thu, 24 Aug 2023 16:49:34 -0700 Subject: [PATCH 2/9] Apply suggestions from code review Co-authored-by: hubwriter --- content/actions/learn-github-actions/variables.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 102119ebb540..7db0e344958d 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -69,16 +69,16 @@ jobs: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" - run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" + run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona ``` {% endraw %} -You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as environment variables in an `echo` command: `env.DAY_OF_WEEK`, `env.Greeting`, and `env.First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." +You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner. Parts of a workflow are interpolated by {% data variables.product.prodname_actions %} and are not sent to the runner. In that case you must use a context to access the variable value. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." -Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `env.NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." +Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." ### Naming conventions for environment variables From 5f34b62ecfa0fe48dce82f2800109514a4dac95f Mon Sep 17 00:00:00 2001 From: Kayla Reopelle Date: Thu, 24 Aug 2023 17:11:41 -0700 Subject: [PATCH 3/9] Clarify the runner as the run step --- content/actions/learn-github-actions/variables.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 7db0e344958d..4f2b52e9ba54 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -76,7 +76,7 @@ jobs: {% endraw %} -You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner. Parts of a workflow are interpolated by {% data variables.product.prodname_actions %} and are not sent to the runner. In that case you must use a context to access the variable value. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." +You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner, i.e. the `run` step. All other parts of a workflow are interpolated by {% data variables.product.prodname_actions %} and are not sent to the runner. In that case you must use a context to access the variable value. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." @@ -222,7 +222,7 @@ You can access environment variable values using the `env` context{% ifversion a In addition to runner environment variables, {% data variables.product.prodname_actions %} allows you to set and read `env` key values using contexts. Environment variables and contexts are intended for use at different points in the workflow. -Runner environment variables are always interpolated on the runner machine. However, parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You can use a context in an `if` conditional statement to access the value of an variable. +Runner environment variables (those referenced in a `run` step) are always interpolated on the runner machine. However, parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You can use a context in an `if` conditional statement to access the value of an variable. {% raw %} @@ -245,7 +245,7 @@ jobs: {% endraw %} -In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAY_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context). +In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAY_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context). The `env` context is not required for the environment variable references within the `run` command because they use the runner's syntax to interpolate the environment variable. {% note %} From 5a4995ea2f313faee954d04faba82a96b14a4962 Mon Sep 17 00:00:00 2001 From: hubwriter Date: Tue, 5 Sep 2023 16:14:47 +0100 Subject: [PATCH 4/9] Add script injection warning --- content/actions/learn-github-actions/variables.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index c827e0822f3a..5af39ee309ce 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -260,6 +260,8 @@ You will commonly use either the `env` or `github` context to access variable va | `env` | Reference custom variables defined in the workflow. | {% raw %}`${{ env.MY_VARIABLE }}`{% endraw %} | | `github` | Reference information about the workflow run and the event that triggered the run. | {% raw %}`${{ github.repository }}`{% endraw %} | +{% data reusables.actions.context-injection-warning %} + {% ifversion actions-configuration-variables %} ### Using the `vars` context to access configuration variable values From 0b484855a002244bb1000d84c26bccd1cfbba2fa Mon Sep 17 00:00:00 2001 From: "Kayla Reopelle (she/her)" <87386821+kaylareopelle@users.noreply.github.com> Date: Wed, 13 Sep 2023 10:21:24 -0700 Subject: [PATCH 5/9] Apply suggestions from code review Co-authored-by: hubwriter --- content/actions/learn-github-actions/variables.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 5af39ee309ce..9d4b5e3ad563 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -78,7 +78,7 @@ jobs: You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner, i.e. the `run` step. All other parts of a workflow are interpolated by {% data variables.product.prodname_actions %} and are not sent to the runner. In that case you must use a context to access the variable value. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." -Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. If the workflow specified a Windows runner, you would use the syntax for PowerShell, `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." +Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. By default, Windows runners use PowerShell, so you would use the syntax `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." ### Naming conventions for environment variables @@ -222,7 +222,9 @@ You can access environment variable values using the `env` context{% ifversion a In addition to runner environment variables, {% data variables.product.prodname_actions %} allows you to set and read `env` key values using contexts. Environment variables and contexts are intended for use at different points in the workflow. -Runner environment variables (those referenced in a `run` step) are always interpolated on the runner machine. However, parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You can use a context in an `if` conditional statement to access the value of an variable. +The `run` steps and in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax `${{ CONTEXT.PROPERTY }}`, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner. + +However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of an variable. {% raw %} @@ -245,7 +247,11 @@ jobs: {% endraw %} -In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAY_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context). The `env` context is not required for the environment variable references within the `run` command because they use the runner's syntax to interpolate the environment variable. +In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAY_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context). The `env` context is not required for the variables referenced within the `run` command. They are referenced as runner environment variables and are interpolated after the job is received by the runner. We could, however, have chosen to interpolate those variables before sending the job to the runner, by using contexts. The resulting output would be the same. + +```yaml +run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" +``` {% note %} From 9a20fe483678d5fd336ecc488dfee127886dfe58 Mon Sep 17 00:00:00 2001 From: "Kayla Reopelle (she/her)" <87386821+kaylareopelle@users.noreply.github.com> Date: Wed, 13 Sep 2023 10:49:06 -0700 Subject: [PATCH 6/9] Update content/actions/learn-github-actions/variables.md --- content/actions/learn-github-actions/variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 9d4b5e3ad563..85b6b9bc8f1f 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -222,7 +222,7 @@ You can access environment variable values using the `env` context{% ifversion a In addition to runner environment variables, {% data variables.product.prodname_actions %} allows you to set and read `env` key values using contexts. Environment variables and contexts are intended for use at different points in the workflow. -The `run` steps and in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax `${{ CONTEXT.PROPERTY }}`, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner. +The `run` steps in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax `${{ CONTEXT.PROPERTY }}`, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner. However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of an variable. From e79b3baee3eecfdf4a760a3b180c13534c0e5d55 Mon Sep 17 00:00:00 2001 From: hubwriter Date: Thu, 14 Sep 2023 10:22:11 +0100 Subject: [PATCH 7/9] Update content/actions/learn-github-actions/variables.md --- content/actions/learn-github-actions/variables.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 85b6b9bc8f1f..6c352957e3e8 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -76,7 +76,9 @@ jobs: {% endraw %} -You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner, i.e. the `run` step. All other parts of a workflow are interpolated by {% data variables.product.prodname_actions %} and are not sent to the runner. In that case you must use a context to access the variable value. For more information on accessing variable values using contexts, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." +You can access `env` variable values using runner environment variables or using contexts. The example above shows three custom variables being used as runner environment variables in an `echo` command: `$DAY_OF_WEEK`, `$Greeting`, and `$First_Name`. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. The interpolation of these variables happens on the runner. + +The commands in the `run` steps of a workflow, or a referenced action, are processed by the shell you are using on the runner. The instructions in the other parts of a workflow are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. You can use either runner environment variables or contexts in `run` steps, but in the parts of a workflow that are not sent to the runner you must use contexts to access variable values. For more information, see "[Using contexts to access variable values](#using-contexts-to-access-variable-values)." Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies `ubuntu-latest`. By default, Linux runners use the bash shell, so you must use the syntax `$NAME`. By default, Windows runners use PowerShell, so you would use the syntax `$env:NAME`. For more information about shells, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)." From 34597075201b46eebad04116b80751a6c2f0f290 Mon Sep 17 00:00:00 2001 From: hubwriter Date: Thu, 14 Sep 2023 10:33:07 +0100 Subject: [PATCH 8/9] Add {% raw %}...{% endraw %} tags --- content/actions/learn-github-actions/variables.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index 6c352957e3e8..c25f41266432 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -224,7 +224,7 @@ You can access environment variable values using the `env` context{% ifversion a In addition to runner environment variables, {% data variables.product.prodname_actions %} allows you to set and read `env` key values using contexts. Environment variables and contexts are intended for use at different points in the workflow. -The `run` steps in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax `${{ CONTEXT.PROPERTY }}`, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner. +The `run` steps in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax {% raw %}`${{ CONTEXT.PROPERTY }}`{% endraw %}, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner. However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of an variable. @@ -251,9 +251,10 @@ jobs: In this modification of the earlier example, we've introduced an `if` conditional. The workflow step is now only run if `DAY_OF_WEEK` is set to "Monday". We access this value from the `if` conditional statement by using the [`env` context](/actions/learn-github-actions/contexts#env-context). The `env` context is not required for the variables referenced within the `run` command. They are referenced as runner environment variables and are interpolated after the job is received by the runner. We could, however, have chosen to interpolate those variables before sending the job to the runner, by using contexts. The resulting output would be the same. +{% raw %} + ```yaml run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" -``` {% note %} From c71da67fe206595f870b0b44f884489ae7fd35fb Mon Sep 17 00:00:00 2001 From: hubwriter Date: Thu, 14 Sep 2023 10:39:50 +0100 Subject: [PATCH 9/9] Add missing {% endraw %} --- content/actions/learn-github-actions/variables.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/actions/learn-github-actions/variables.md b/content/actions/learn-github-actions/variables.md index c25f41266432..a8a63bd97993 100644 --- a/content/actions/learn-github-actions/variables.md +++ b/content/actions/learn-github-actions/variables.md @@ -255,6 +255,9 @@ In this modification of the earlier example, we've introduced an `if` conditiona ```yaml run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" +``` + +{% endraw %} {% note %}