Update evaluate-expressions-in-workflows-and-actions.md

[dmail]

Why:

I want to have a dynamic path depending on runner.os in a GitHub workflow. See https://github.com/microsoft/playwright/issues/7249 for the context.

The documentation at https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions helped me. However even with all that documentation it took me a long time to make it work. I would like to add an example to help others that would face a similar use case.

Closes: Nothing

What's being changed (if available, include any code snippets, screenshots, or gifs):

This pull request add an example where a value is a path dynamic per OS.

This example uses format and env.HOME to build the path on windows, something as follow:

path: format('{0}{1}', env.HOME, '\AppData\Local\ms-playwright')

This means something before have to set env.HOME which can be achieved like this:

- name: Put $HOME in env
  if: runner.os == 'windows'
  run: echo "HOME=$HOME" | Out-File -FilePath $env:GITHUB_ENV -Append

I don't know if this should be added to the documentation but if we don't add it people will have trouble to make it work.

I hope you'll find this useful, thank you.

Check off the following:

• [x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• [x] For content changes, I have completed the self-review checklist.

[welcome[bot]]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions[bot]]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions.md	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10

---

fpt: Free, Pro, Team ghec: GitHub Enterprise Cloud ghes: GitHub Enterprise Server

[nguyenalex836]

@dmail Thanks so much for opening a PR! I'll get this triaged for review ✨

[github-actions[bot]]

Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert :eyes:

[nguyenalex836]

@dmail Thank you very much for your patience while our SME team reviewed your PR! ✨ Our SME team provided the following feedback on why we are unfortunately unable to accept this PR:

I would like to add an example to help others that would face a similar use case.

I feel that this document is intentionally devoid of specific use-cases unless those use-cases are illustrative and educational in some way. I came to this conclusion by comparing to other examples on this page:

• Immediately preceding example for operators
  • The example uses placeholder names and GitHub/Git specific concepts like refs that are applicable and understandable (hopefully) to everyone working with GitHub writing actions workflows.
• Object filters
  • The example presented is abstract using fruits as example values to illustrate the concepts using common object data names and qualities that we all understand well.

In both examples, the use-case of the example is not the focus; instead, the focus to demonstrate the workflow syntax using common ground the reader is likely familiar with.

Comparing these examples to the proposed changes, I see these differences:

• The example does not use placeholder names and involves subject matter very specific to the use-case (playwrite paths & checking the runner.os context variable).
• The example is not exclusively illustrative of actions workflow syntax concepts; instead it demonstrates this user’s use case.

What could be changed to make this PR acceptable?

• Remove over-specific subject matter (playwrite) and replace with generic or (mostly) universally subject matter.
• Add a written explanation, walking the reader through what is happening in the example. See how the immediately preceding example for operators does this. If this isn’t possible or seems unnecessary (if we are just repeating the explanation from the previous example), then it suggests that this example isn’t actually bringing any new learning to the table beyond the introduction of third-party/external subject matter like playwrite and the overall use-case.

We greatly appreciate your time putting together this PR, and if you have any feedback regarding the response our SME team provided, please let us know! 💛

[github-actions[bot]]

This PR has been automatically closed because there has been no response to to our request for more information from the original author. Please reach out if you have the information we requested, or open a new issue to describing your changes. Then we can begin the review process.