Tag in vcpkgCommitId

[Shatur]

If I understand correctly, then vcpkgCommitId cannot contain a tag. But if you specify it, then I will get silently non-working cache. Workflow output with tag in vcpkgCommitId (the cache is unpacked but not used).

[Shatur]

Is it possible to add tagging support to vcpkgCommitId?

[lukka]

@Shatur95 yes, it would be possible, no ETA though.

Instead of specifying a tag, or a commit id, the best practice is to use vcpkg as a submodule, so that the vcpkg used is exactly the same locally and on CI.

[Shatur]

Instead of specifying a tag, or a commit id, the best practice is to use vcpkg as a submodule, so that the vcpkg used is exactly the same locally and on CI.

Yes, I know, but I only need vcpkg on Windows, because on Linux I need to build a package with the versions of the libraries that are in the official repository. I would even okay with #35 or #44 to have latest possible versions of the libraries.

[lukka]

Please take a look to run-vcpkg@v10 and see if suites your needs. Feel free to reopen this or a new ticket about any problem you may see.

[Shatur]

The description still stays that a tag name as a vcpkgCommitId is forbidden:

run-vcpkg/action.yml

Line 24 in 61e8552

description: "Specify the full SHA-1 hash of a Git commit (not a branch name, nor a tag!) that establishes which version of vcpkg needs to be used. When using vcpkg as a Git submodule, this input is *not* needed as implicitly specified by the submodule."

[lukka]

@Shatur right, tags are not supported. Reopening this item.

[justusranvier]

the best practice is to use vcpkg as a submodule

I guess you've never run into this issue before, but using vcpkg as a submodule is actually a terrible idea if you need to run vcpkg on windows images because of the MAX_PATH issue.

There are several packages in vcpkg whose build process runs right up to the limit and only work if you use C:\VCPKG. Any base path longer than that and you'll get hard to diagnose failures and confusing error messages that take a long time to track back to their root cause.

[lukka]

@justusranvier hitting the MAX_PATH limitation is certainly a nightmare that forces unnecessary changes to workaround it.
The most important thing is to pin a specific version of vcpkg, so that the build reliably works in the same way for build executed by the devs and on CI build agent. Pinning using "vcpkg as a submodule" is one way, but certainly there can be others as long as they are stored in the source control. Which other approach would you suggest? A PR to improve the current best practices content is welcome.

There are also other questions as well that would help in narrowing down the problem and probably delineating a solution:

• what is the extent of the problem of pinning the vcpkg version using a Git submodule? Is it a complete failure in any case, or only surfacing when some port is being used? This best practice is described in the vcpkg.io, and problem with it should be highlighted to the vcpkg project as an GH issue.
• are you using a self hosted agent? I do not have a direct experience about this, but hopefully the Windows hosted agents are setup to not hit the MAX_PATH limitation.

[justusranvier]

• Is it a complete failure in any case, or only surfacing when some port is being used?

Not all ports will result in exceeding MAX_PATH, but qtdeclarative and its dependencies will unless the base path is very short (C:\VCPKG)

but hopefully the Windows hosted agents are setup to not hit the MAX_PATH limitation

From my experience the hosted runners do hit MAX_PATH. I have read there are registry hacks to turn off this limitation but they require a reboot so there's no way to use them in a hosted runner.

[lukka]

Closing as more than one year of inactivity. Feel free to ask to reopen if needed.