Commit id fetching doesn't work if checked out to a subdirectory
Here is a repro commit.
This uses vcpkg as a submodule and the repository is checked out to the "plugin" subdirectory. The following is printed in this action:
Running command '/usr/bin/git' with args 'submodule,status,/home/runner/work/RewardsTheater/RewardsTheater/plugin/vcpkg' in current directory '/home/runner/work/RewardsTheater/RewardsTheater'.
fatal: not a git repository (or any of the parent directories): .git
That's because this git status command is run in /home/runner/work/RewardsTheater/RewardsTheater which is indeed not a git repository—the plugin subdirectory is.
This is a regression: such an error wasn't occuring on 6fe69898af670ac05f4a8427cc5cff4fb361cee5. With that commit, it instead runs (as expected)
Running command '/usr/bin/git' with args 'rev-parse,HEAD' in current directory '/home/runner/work/RewardsTheater/RewardsTheater/plugin/vcpkg'.
@gottagofaster236 thank you for reporting this issue! The run-vcpkg action makes the assumption that the GitHub workspace directory contains a Git repository whose vcpkg is a submodule of. You should be able to set the process.env.GITHUB_WORKSPACE to any value you want to get the behaviour you want. For example:
uses: lukka/run-vcpkg@v11
[...]
env:
GITHUB_WORKSPACE: ${{ github.workspace }}/plugins
I hope that above suggestion works good, if it does not, I look forward to a community provided PR to find a solution for this.
Adding a "GITHUB_WORKSPACE" environment variable didn't change the current directory unfortunately
@gottagofaster236 could you enable debugging log for GH action? I wonder if the verbose log could shed some light in why the code here does not pick the environment variable set.
Another workaround would be to try setting the GITHUB_WORKSPACE at job level, that is:
[...]
env:
GITHUB_WORKSPACE: ${{ github.workspace }}/plugins
jobs:
[...]
or probably my suggestion is totally off because the runner is always going to setup and force the GITHUB_WORKSPACE env var hence defeating this suggestion :/
Here's the run with debugging log enabled
Another workaround would be to try setting the GITHUB_WORKSPACE at job level
I think it can break other unrelated jobs so I would rather not do that
@gottagofaster236 thank you for providing the verbose log, though I can't see why the suggested workaround does not work. Probably you may workaround it by putting the vcpkg commit id in the vcpkg.json file, although not ideal.
Regarding fixing run-vcpkg to support such scenario, I think it would suffice to change the isVcpkgSubmodule function to use as cwd the fullVcpkgPath parent directory (i.e. one level up only), add a test to cover this scenario and hopefully nothing else gets regressed (which should be spotted by existing tests).
I look forward to see a community provided PR to fix this issue. Of course I'll try this as well but I am not making any promise.