Commit id fetching doesn't work if checked out to a subdirectory about run-vcpkg

[lukka]

@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.

[lukka]

@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.

[gottagofaster236]

Adding a "GITHUB_WORKSPACE" environment variable didn't change the current directory unfortunately

[lukka]

@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 :/

[gottagofaster236]

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