Manifest Mode and Recursive Submodules

[spinicist]

Hello,

I wanted to try the new manifest mode cacheing but hit a problem. I recently changed the way I include vcpkg in my repos - it is now a submodule of a submodule. My repo structure now looks like:

root/
     cmake/ <- Submodule that includes my toolchains, which include vcpkg, and a few helper files
           vcpkg/ <- vcpkg submodule

which you can see for real here: https://github.com/spinicist/riesling/tree/tests. I ended up with this structure after discussing with some vcpkg engineers how best to include Address Sanitizer.

run-vcpkg fails to detect that vcpkg is a sub-module in this situation, and gives this error message:

run-vcpkg action execution failed: 'Error: 'vcpkgGitCommitId' input parameter must be provided when the specified vcpkg directory (/home/runner/work/riesling/riesling/cmake/vcpkg) is not a submodule.

However if I provide a vcpkg commit ID, I then get the following error:

Check whether vcpkg repository is up to date
45
  Checking whether vcpkg's repository is updated to commit id '1b5a98571e3e68080d665f20705fb10d8d3c97d4' ...
46
  tool: /usr/local/bin/git
47
  error: pathspec '/Users/runner/work/riesling/riesling/cmake/vcpkg' did not match any file(s) known to git
48
  Current commit id of vcpkg: '1b5a98571e3e68080d665f20705fb10d8d3c97d4'.
49
  Is vcpkg repository updated? No

Run logs in both situations can be found here: https://github.com/spinicist/riesling/actions/runs/449601569 and here: https://github.com/spinicist/riesling/runs/1619416104.

Is there a way run-vcpkg can be made aware of recursive submodules?

[lukka]

@spinicist yes, it could be done, at the moment only first level submodules are taken into account.

At the very end, it's best to tailor the workflow to your need by using directly the tools you really need and that you can run and test directly on your box rather than relying on GitHub actions.

Please have a look to how to create a workflow without (too many) GitHub actions in here: lukka/run-cmake#41

The idea is that GitHub actions are useful only if strictly necessary and fit your purpose.

[spinicist]

I agree overall - but specifically with regards to persisting vcpkg's cache, I have no idea how to do that without an action!

(The rest of my build can be described in a 3 line shell script which is actually how I do it on my machine).

[lukka]

@spinicist i'll take a note about the added values of this GitHub action: automatic cache "done right".
About how GitHub caching service works, I added documentation (just few comments) to the pure workflow.

Note that (quite ridiculously) the action/cache is broken regarding the path exclusion, which makes the created cache to be gigantic :/

[spinicist]

Thanks!