Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of defaults.run.working-directory #187

Open
jbelien opened this issue Oct 6, 2021 · 7 comments
Open

Use of defaults.run.working-directory #187

jbelien opened this issue Oct 6, 2021 · 7 comments

Comments

@jbelien
Copy link

jbelien commented Oct 6, 2021

First things first, thanks a lot for this GitHub Actions workflow ! 👍

I see that there is the composer-options that allow to specify the working directory with --working-dir=foo if the composer.json file is in the foo sub-directory.

I'm using the defaults.run.working-directory in my workflow:

defaults:
  run:
    working-directory: foo/

Is there a way to make ramsey/composer-install use that defaults.run.working-directory if it is specified ?

Thanks!

@Kocal
Copy link
Contributor

Kocal commented Oct 6, 2021

Hi, see https://github.com/ramsey/composer-install#alternate-composerjson-locations.

Using --workding-dir in your composer-options will automatically change the working directory (see related PR #107)

@jbelien
Copy link
Author

jbelien commented Oct 6, 2021

Yes, that works indeed perfectly fine.

My question was about not having to specify --workding-dir in my composer-options if defaults.run.working-directory is specified.
Am I missing something ?

ramsey added a commit that referenced this issue Dec 23, 2021
This also adds the following features:

- Use `--prefer-stable` with lowest dependencies (#178)
- Allow use of a custom cache key (#167)
- Allow ability to ignore the cache

Fixes: #187, #161, #152, #79
ramsey added a commit that referenced this issue Dec 23, 2021
This also adds the following features:

- Use `--prefer-stable` with lowest dependencies (#178)
- Allow use of a custom cache key (#167)
- Allow ability to ignore the cache

Fixes: #187, #161, #152, #79
ramsey added a commit that referenced this issue Dec 23, 2021
This also adds the following features:

- Use `--prefer-stable` with lowest dependencies (#178)
- Allow use of a custom cache key (#167)
- Allow ability to ignore the cache

Fixes: #187, #161, #152, #79
@ramsey
Copy link
Owner

ramsey commented Dec 23, 2021

This is fixed in v2, please upgrade using ramsey/composer-install@v2 or ramsey/composer-install@2.0.0. Details are available on the release announcement and the README.

Thanks!

@ramsey ramsey closed this as completed Dec 23, 2021
@jbelien
Copy link
Author

jbelien commented Dec 24, 2021

Thanks a lot @ramsey ! 👍

Will it work with defaults.run.working-directory (default configuration) or do I still need to specify working-directory as input ?

@ramsey
Copy link
Owner

ramsey commented Dec 24, 2021

Hmm. That's a good question. If defaults.run.working-directory tells GitHub to run everything from that directory, it should work accordingly, as long as your composer.json isn't in some place other than defaults.run.working-directory. Let me know if it doesn't work.

@jbelien
Copy link
Author

jbelien commented Jan 5, 2022

Hmm. That's a good question. If defaults.run.working-directory tells GitHub to run everything from that directory, it should work accordingly, as long as your composer.json isn't in some place other than defaults.run.working-directory. Let me know if it doesn't work.

I just tried and it doesn't work if I just specify defaults.run.working-directory

Error: Unable to find composer.json at './composer.json'

I tried stuff like the following but it doesn't seem to be "supported" by GitHub Actions.

- uses: ramsey/composer-install@v2
  with:
    working-directory: ${{ defaults.run.working-directory }}

But using working-directory with the correct path in ramsey/composer-install@v2 works as expected! 👍

@ramsey
Copy link
Owner

ramsey commented Jan 5, 2022

Thanks for reporting back your findings. I'll need to look into this. It does make sense that it should respect the current working directory of the job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants