Confusion and caching issues

[HunterZ]

Got this working, but I don't think it's caching my stuff. Meanwhile, I am confused about some aspects of it:

First, other stuff I've read encourage me to pull in vcpkg as a submodule of my project, but this Action wants to clone vcpkg into the runner workspace instead, so I had to use a workaround to init all submodules except vcpkg. Would it be possible for this Action to support using vcpkg as a submodule? (Edit: I've backed out of using it as a submodule for now, since I wasn't thrilled about it in the first place)

Second, I'm confused about steps.vcpkg.outputs.vcpkg-cmake-config:

• I'm using manifest mode, and this variable turns that off - is that intended?
• Also, do I need to use steps.vcpkg.outputs.vcpkg-cmake-config for caching to work?

Third, caching doesn't seem to be working consistently. For example, this workflow run on the final commit to my CI/CD development branch completed in 3 minutes: https://github.com/HunterZ/rustLaunchSite/actions/runs/7947199387/job/21695744049 ...but this workflow run over the same git repo contents after merging my branch to main took over 13 minutes, which is twice as long as running vcpkg without an Action: https://github.com/HunterZ/rustLaunchSite/actions/runs/7947262070/job/21695877873

Is there something I'm doing wrong? Here is my workflow YAML: https://github.com/HunterZ/rustLaunchSite/blob/9fb24d8d63dabdbed5e4865a4ebe241fb0629c10/.github/workflows/rustLaunchSite.yml

[johnwason]

First, other stuff I've read encourage me to pull in vcpkg as a submodule of my project

I would not recommend doing this. Not only will this cause users to clone the large vcpkg repository, it also means that the users will not get the most up to date version of vcpkg.

I'm using manifest mode, and this variable turns that off - is that intended? Also, do I need to use steps.vcpkg.outputs.vcpkg-cmake-config for caching to work?

This action runs the manifest build separately and then uses steps.vcpkg.outputs.vcpkg-cmake-config to disable the rebuild and point to the built files. Using the new github cache method this may not be necessary.

Using this action may not be the best choice for your scenario. You can directly use vcpkg caching: https://learn.microsoft.com/en-us/vcpkg/users/binarycaching#gha

[HunterZ]

Thanks.

I've almost got this working, but when I bring in steps.vcpkg.outputs.vcpkg-cmake-config, the MSYS2 MinGW64 build breaks with std::codecvt linker errors that don't occur without it (nor if I drive vcpkg directly instead of via your action): https://github.com/HunterZ/rustLaunchSite/actions/runs/8016038485/job/21897224717

I suspect the problem may be that the action is invoking vcpkg.exe install in a cmd shell, which probably doesn't get it full access to my MSYS2 MinGW environment. I've got the MSYS2 shell configured as default, but the action presumably overrides that on Windows runners.

I guess that means I'll have to ditch your action and figure out the caching stuff you linked.

[HunterZ]

Update: Got caching working with vcpkg invoked via CMake - thanks again!

Working YAML: https://github.com/HunterZ/rustLaunchSite/blob/06728d65ba42cf7fda7738c656a137c5fb53806a/.github/workflows/rustLaunchSite.yml

Ran with an empty cache, then ran again. vcpkg reported use of cache, and workflow time dropped by about 6 minutes:

• MinGW64: 10m33s -> 4m25s (MSYS2 setup is a bear)
• MSVC: 8m10s -> 2m29s