Use builtin-baseline from vcpkg.json

[Shatur]

I would suggest to support builtin-baseline (reference). It could replace vcpkgGitCommitId.

[lukka]

@Shatur If i get this right this is the suggestion:

run-vcpkg could read the Git commit id from the vcpkg.json when

• thevcpkgGitCommitId input is not provided.
• the vcpkg.json file has been found.
• vcpkg is not present in a Git submodule.

[Shatur]

@lukka Exactly!

[equeim]

FYI: vcpkg also allows to specify its commit id in vcpkg-configuration.json - https://github.com/microsoft/vcpkg/blob/master/docs/users/versioning.md#builtin-baseline
I thing that vcpkg-configuration.json should also be hashed to cache key, too.

[lukka]

the original suggestion is to save the user to specify a value for vcpkgGitCommitId when this information is already stored in the vcpkg.json file (i.e. to avoid duplication).
@equeim What you suggest is unrelated, and procedurally you are asking the following:

• if a vcpkg-configuration.json is found side by side with the previously identified vcpkg.json, then compute an hash of its content as well and append it into the cache key.
  Is this correct? If so, this is worth a new separated issue I believe.

[equeim]

Yeah, second point about hashing was unrelated, I added it because I mentioned vcpkg-configuration.json and noticed that run-vcpkg doesn't hash it by default. Sorry for the confusion.

What I meant was that baseline commit can be specified in both vcpkg.json and vcpkg-configuration.json. In the second form it would look like this object inside root object in vcpkg-configuration.json:

  "default-registry": {
    "kind": "builtin",
    "baseline": "df40d1c476dc02d71b113e4a63c3a32b00ebb5bd"
  }

So the logic that will look for commit id in vcpkg.json will also need to look in vcpkg-configuration.json. If both files have baseline commit, then vcpkg will use one provided in vcpkg-configuration.json.

[lukka]

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

[BurningEnlightenment]

AFAICT this hasn't been implemented and I often forget to update the Workflow after updating the baseline in vcpkg-configuration.json

[lukka]

@BurningEnlightenment is the ask to implement this:

run-vcpkg could read the Git commit id from the vcpkg.json when

- the vcpkgGitCommitId input is not provided.
- the vcpkg.json file has been found.
- vcpkg is not present in a Git submodule.

[BurningEnlightenment]

@lukka almost, there are a few key differences:

run-vcpkg could read the Git commit id from the vcpkg-configuration.json when

- the vcpkgGitCommitId input is not provided.
- vcpkg is not present in a Git submodule.
- vcpkg-configuration.json has been found
- the vcpkg-configuration.json contains a property akin to
    "default-registry": {
        "kind": "builtin",
        "baseline": "f6a5d4e8eb7476b8d7fc12a56dff300c1c986131"
    }

Here is a typical baseline update commit: deeplex/deeppack@bea8a58 As you can see I have to manually keep my CI Workflows and vcpkg-configuration.json in sync.

[lukka]

@BurningEnlightenment what about this simplified solution:

if the newly added vcpkgConfigurationGlob input is provided, the glob expression (i.e., its value) is used to locate the vcpkg-configuration.json file:

• if found, the baseline is used.
• if not found, or if the baseline is not present, it fails.

Notes:

• the vcpkgConfigurationGlob should not be provided if vcpkg is identified as a submodule, it will error out in that case.
• the vcpkgConfigurationGlob should not be provided along vcpkgCommitId, it will error out in that case.

Open points:

• I have no experience with vcpkg-configuration.json, so I do not know and haven't tried, and here my question as a non informed person: shouldn't vcpkg just checkout the right commit id when fetching the port files? That is, is it really required to have the vcpkg repo at the baseline commit id? I thought vcpkg would be able to fetch ports files by any available commit id, as long as the SHA1 is part of the history. If you just update the baseline in vcpkg-configuration.json (and forget to update in the vcpkgCommitId input), how would the workflow fail?

[BurningEnlightenment]

I'm fine with the simplified solution. About your questions:

shouldn't vcpkg just checkout the right commit id when fetching the port files? That is, is it really required to have the vcpkg repo at the baseline commit id?

Well, yes and no. vcpkg looks into the direct git history of the currently checked-out commit to find the baseline commit. So it doesn't suffice to just have fetched the baseline commit. In that sense it would suffice to simply clone and checkout the vcpkg master branch.

However, currently this action requires you to specify a commit id for cache-key computation and because it otherwise refuses to clone the repository at all: https://github.com/lukka/run-cmake-vcpkg-action-libs/blob/1603dc514460c9f5c54a5ffe924dedc042eb75d2/packages/run-vcpkg-lib/src/vcpkg-runner.ts#L357-L359

I've prepared a demo PR for this issue: deeplex/concrete#31
You can observe the failure caused by checking out a parent commit of the baseline (as opposed to the baseline or a child) here: https://github.com/deeplex/concrete/actions/runs/6776278659/job/18417400964#step:5:42
And how it works again after updating the workflow file: https://github.com/deeplex/concrete/actions/runs/6776324179/job/18417555910#step:5:54
(ignore the ubuntu-22.04-clang failure which is due to a broken dependency)

[lukka]

You may want to test out run-vcpkg@dev/vcpkgconfjson-support. Still more testing/validation and docs should be added, but the functionality should be there. Feedback is appreciated.

Note: currently when vcpkgGitCommitId is not provided and vcpkg is not a Git submodule, run-vcpkg tries to fetch the Git commit id from the baseline vcpkg-configuration.json file, which is located using the glob expression defined at input vcpkgConfigurationJsonGlob.