ci/cd: add vcpkg release automation and policy enforcement#1599
ci/cd: add vcpkg release automation and policy enforcement#1599
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📝 WalkthroughWalkthroughAdds vcpkg as a git submodule, two GitHub Actions workflows to update and verify the vcpkg baseline, a verification script to confirm the baseline matches a vcpkg release tag, updates CMake presets to use the submodule toolchain, and documents vcpkg policy plus Docker build/run instructions. Changes
Sequence DiagramsequenceDiagram
participant Scheduler as Scheduler / Manual Trigger
participant GH as GitHub Actions
participant Repo as Repository (with submodules)
participant Vcpkg as microsoft/vcpkg
participant PR as Pull Request
Scheduler->>GH: trigger update-vcpkg workflow
GH->>Repo: checkout repository (with submodules)
GH->>Vcpkg: query tags (git ls-remote) / resolve latest release tag
Vcpkg-->>GH: return latest tag
GH->>Repo: add/update `external/vcpkg` submodule, fetch tags, checkout tag
GH->>Repo: bootstrap vcpkg and run `vcpkg x-update-baseline`
GH->>PR: create branch `chore/vcpkg-update-{tag}`, commit changes, open PR with labels
PR-->>GH: PR created/updated
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/update-vcpkg-release.yml:
- Around line 49-50: The YAML keys commit-message and title contain unquoted
strings with colons which breaks parsing; update the workflow step to quote the
values for commit-message and title (e.g., wrap the existing templates used in
commit-message and title in single or double quotes) so the colon characters are
treated as part of the string rather than YAML syntax.
- Around line 39-42: The workflow step named "Update vcpkg builtin-baseline"
invokes the experimental command "./external/vcpkg/vcpkg x-update-baseline",
which may change or be removed; update the workflow to guard and document this
by (1) adding an inline comment or annotation near the step that notes the
command is experimental, (2) pinning or checking the vcpkg version/commit used
by "./external/vcpkg/bootstrap-vcpkg.sh" so upgrades are explicit, and (3)
optionally adding a pre-check (e.g., run "./external/vcpkg/vcpkg --version" or
query "vcpkg help x-update-baseline") to skip or fail with a clear message if
the installed vcpkg does not support x-update-baseline.
In `@tools/verify-vcpkg-baseline-is-release.sh`:
- Around line 1-2: The script tools/verify-vcpkg-baseline-is-release.sh is
missing the executable permission which causes CI to fail; fix it by setting the
executable bit (chmod +x) on that file in the repository and commit the
permission change so the CI runner can execute the script (ensure the commit
includes the updated file mode).
🧹 Nitpick comments (2)
tools/verify-vcpkg-baseline-is-release.sh (1)
11-13: Consider cleaning up the temporary directory after execution.The script creates a temporary directory but doesn't clean it up on success. Consider adding cleanup at the end or using a trap for cleanup on exit.
♻️ Suggested improvement
tmp_dir=".tmp/vcpkg-tags" rm -rf "${tmp_dir}" mkdir -p "${tmp_dir}" +trap 'rm -rf "${tmp_dir}"' EXIT.github/workflows/verify-vcpkg-baseline.yml (1)
17-18: Usebashto invoke the script to work around permission issues.While the script should have execute permission set (addressed separately), invoking with
bashexplicitly provides a fallback and makes the execution more explicit.♻️ Suggested fix
- name: Verify vcpkg builtin-baseline is a release tag - run: tools/verify-vcpkg-baseline-is-release.sh + run: bash tools/verify-vcpkg-baseline-is-release.sh
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/update-vcpkg-release.yml.github/workflows/verify-vcpkg-baseline.yml.gitmodulesREADME.mdtools/verify-vcpkg-baseline-is-release.sh
🧰 Additional context used
🪛 actionlint (1.7.10)
.github/workflows/update-vcpkg-release.yml
49-49: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 GitHub Actions: Verify vcpkg baseline
tools/verify-vcpkg-baseline-is-release.sh
[error] 1-1: Permission denied executing script. Command failed with exit code 126.
🪛 YAMLlint (1.37.1)
.github/workflows/update-vcpkg-release.yml
[error] 49-49: syntax error: mapping values are not allowed here
(syntax)
🔇 Additional comments (5)
.gitmodules (1)
1-3: LGTM!The submodule configuration is correct and follows standard conventions. Using the official Microsoft vcpkg repository URL is appropriate.
tools/verify-vcpkg-baseline-is-release.sh (1)
21-28: Verify the tag validation logic matches the intended policy.The current logic uses
git tag --containswhich finds tags whose history includes the baseline commit. This means an older commit will match newer release tags that descended from it.If the intent is to verify the baseline is a release tag (i.e., the exact commit), use
git tag --points-atinstead:♻️ Alternative if exact release tag commit is required
-tags=$(git -C "${tmp_dir}" tag --contains "${baseline_sha}") +tags=$(git -C "${tmp_dir}" tag --points-at "${baseline_sha}")If the current behavior (allowing any commit contained within a release) is intentional, consider adding a comment to clarify this design decision.
.github/workflows/update-vcpkg-release.yml (2)
20-28: LGTM!The tag resolution logic correctly fetches and sorts vcpkg release tags using version sort (
sort -V), which handles vcpkg's date-based tag format appropriately.
30-37: Submodule handling looks reasonable.The defensive check for submodule existence is appropriate for handling both fresh setups and existing configurations.
README.md (1)
520-526: LGTM!The vcpkg policy documentation is clear and provides essential information about baseline requirements, automated updates, and the recommended toolchain path. This aligns well with the automation workflows being added.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| - name: Update vcpkg builtin-baseline | ||
| run: | | ||
| ./external/vcpkg/bootstrap-vcpkg.sh | ||
| ./external/vcpkg/vcpkg x-update-baseline |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
vcpkg x-update-baseline command documentation
💡 Result:
Summary of vcpkg x-update-baseline (experimental)
- Synopsis: vcpkg x-update-baseline [options] [--add-initial-baseline] [--dry-run]. [1]
- Purpose: Update baselines for all configured registries (operates on vcpkg.json and vcpkg-configuration.json in Manifest mode; on vcpkg-configuration.json in $VCPKG_ROOT in Classic mode). See versioning docs for details. [1]
- Options:
- --dry-run: print planned baseline upgrades without modifying files. [1]
- --add-initial-baseline (Manifest mode only): add a "builtin-baseline" field to vcpkg.json if missing; without it running on a manifest with no registries is an error. [1]
- Note: feature is experimental and may change or be removed. [1][2]
Sources: Microsoft Learn documentation for vcpkg x-update-baseline. [1][2]
Note the x-update-baseline command is experimental.
The bootstrap and x-update-baseline workflow is correct, but be aware that x-update-baseline is marked as experimental in vcpkg and may change or be removed in future releases. This should be monitored when upgrading vcpkg versions.
🤖 Prompt for AI Agents
In @.github/workflows/update-vcpkg-release.yml around lines 39 - 42, The
workflow step named "Update vcpkg builtin-baseline" invokes the experimental
command "./external/vcpkg/vcpkg x-update-baseline", which may change or be
removed; update the workflow to guard and document this by (1) adding an inline
comment or annotation near the step that notes the command is experimental, (2)
pinning or checking the vcpkg version/commit used by
"./external/vcpkg/bootstrap-vcpkg.sh" so upgrades are explicit, and (3)
optionally adding a pre-check (e.g., run "./external/vcpkg/vcpkg --version" or
query "vcpkg help x-update-baseline") to skip or fail with a clear message if
the installed vcpkg does not support x-update-baseline.
| #!/usr/bin/env bash | ||
| set -euo pipefail |
There was a problem hiding this comment.
Missing executable permission causes pipeline failure.
The script lacks execute permission, which causes the CI workflow to fail with exit code 126. Add executable permission to the script.
chmod +x tools/verify-vcpkg-baseline-is-release.shThen commit the change to fix the permission in the repository.
🧰 Tools
🪛 GitHub Actions: Verify vcpkg baseline
[error] 1-1: Permission denied executing script. Command failed with exit code 126.
🤖 Prompt for AI Agents
In `@tools/verify-vcpkg-baseline-is-release.sh` around lines 1 - 2, The script
tools/verify-vcpkg-baseline-is-release.sh is missing the executable permission
which causes CI to fail; fix it by setting the executable bit (chmod +x) on that
file in the repository and commit the permission change so the CI runner can
execute the script (ensure the commit includes the updated file mode).
f1031f5 to
ba9442e
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@CMakePresets.json.rej`:
- Around line 1-151: The repository contains a rejected patch file
(CMakePresets.json.rej) that must not be committed; open the original
CMakePresets.json, resolve the merge conflicts, apply the intended change by
updating the CMAKE_TOOLCHAIN_FILE cacheVariable values to
"${sourceDir}/external/vcpkg/scripts/buildsystems/vcpkg.cmake" (look for the
"CMAKE_TOOLCHAIN_FILE" entries in presets like "windows-release",
"linux-release", "macos-release"), verify the presets are valid JSON and
preserve other cacheVariables, then remove the .rej file and commit only the
resolved CMakePresets.json.
♻️ Duplicate comments (3)
tools/verify-vcpkg-baseline-is-release.sh (1)
1-2: Missing executable permission causes pipeline failure.The script requires executable permission to run in CI. Ensure the file has the execute bit set.
chmod +x tools/verify-vcpkg-baseline-is-release.sh git add tools/verify-vcpkg-baseline-is-release.sh.github/workflows/update-vcpkg-release.yml (2)
39-42: Note:x-update-baselinecommand is experimental.This command may change or be removed in future vcpkg releases. Monitor vcpkg changelog when upgrading.
49-50: YAML syntax error: values containing colons must be quoted.The
commit-messageandtitlevalues contain colons which require quoting to be valid YAML. Static analysis confirms this error.🐛 Proposed fix
- commit-message: chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }} - title: chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }} + commit-message: "chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }}" + title: "chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }}"
🧹 Nitpick comments (1)
tools/verify-vcpkg-baseline-is-release.sh (1)
11-13: Consider cleaning up the temporary directory.The temporary directory
.tmp/vcpkg-tagsis created but not removed on successful completion. Consider adding a cleanup trap.♻️ Suggested improvement
tmp_dir=".tmp/vcpkg-tags" rm -rf "${tmp_dir}" mkdir -p "${tmp_dir}" +trap 'rm -rf "${tmp_dir}"' EXIT
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/update-vcpkg-release.yml.github/workflows/verify-vcpkg-baseline.yml.gitmodulesCMakePresets.json.rejREADME.mdtools/verify-vcpkg-baseline-is-release.sh
✅ Files skipped from review due to trivial changes (1)
- .gitmodules
🧰 Additional context used
🪛 actionlint (1.7.10)
.github/workflows/update-vcpkg-release.yml
49-49: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 YAMLlint (1.37.1)
.github/workflows/update-vcpkg-release.yml
[error] 49-49: syntax error: mapping values are not allowed here
(syntax)
🔇 Additional comments (5)
tools/verify-vcpkg-baseline-is-release.sh (1)
20-28: LGTM!The tag verification logic is sound—fetching tags first, then the specific baseline commit, and using
git tag --containsto verify containment. Error handling is appropriate..github/workflows/verify-vcpkg-baseline.yml (1)
1-18: LGTM!The workflow is well-structured with appropriate triggers for both push and pull request events. Using
bashto invoke the script explicitly avoids permission issues during execution..github/workflows/update-vcpkg-release.yml (2)
20-28: Tag resolution logic looks correct for vcpkg's date-based tags.The
sort -Vapproach works for vcpkg'sYYYY.MM.DDtag format. Error handling for empty results is appropriate.
30-37: LGTM!The submodule update logic correctly handles both fresh setups (adding the submodule if missing) and existing configurations. The sequence of init, fetch, and checkout ensures the submodule is at the desired tag.
README.md (1)
520-526: LGTM!The vcpkg policy documentation is clear and aligns well with the automation workflows added in this PR. It properly documents:
- The baseline constraint (must be a release tag)
- The automated update mechanism
- The expected toolchain path
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
ba9442e to
d1bc762
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/update-vcpkg-release.yml:
- Around line 48-55: Replace the conditional git submodule add logic with an
unconditional git submodule update --init --recursive for external/vcpkg to
avoid failing when .gitmodules contains the entry but the directory is missing;
keep a separate guard that only runs git submodule add
https://github.com/microsoft/vcpkg.git external/vcpkg if .gitmodules does not
contain the vcpkg entry (or if .gitmodules is absent), otherwise always run git
-C external/vcpkg fetch --tags origin and git -C external/vcpkg checkout "${{
steps.vcpkg_tag.outputs.tag }}" so the workflow handles shallow clones and
missing directories safely.
♻️ Duplicate comments (2)
CMakePresets.json.rej (1)
1-151: Do not commit.rejfiles to the repository.This rejected patch file should not be committed. Resolve the merge conflict in
CMakePresets.jsondirectly, apply the intended toolchain path changes, and delete this.rejfile..github/workflows/update-vcpkg-release.yml (1)
67-68: YAML syntax error: values containing colons must be quoted.The
commit-messageandtitlevalues contain colons which require quoting to be valid YAML.🐛 Proposed fix
- commit-message: chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }} - title: chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }} + commit-message: "chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }}" + title: "chore(vcpkg): update to latest vcpkg release ${{ steps.vcpkg_tag.outputs.tag }}"
🧹 Nitpick comments (4)
tools/verify-vcpkg-baseline-is-release.sh (3)
4-4: Add error handling for missingvcpkg.jsonor missing key.If
vcpkg.jsondoesn't exist or lacksbuiltin-baseline, Python raises an exception. Consider a clearer error message.♻️ Suggested improvement
-baseline_sha=$(python3 -c 'import json; print(json.load(open("vcpkg.json"))["builtin-baseline"])') +baseline_sha=$(python3 -c ' +import json, sys +try: + data = json.load(open("vcpkg.json")) + print(data.get("builtin-baseline", "")) +except FileNotFoundError: + print("vcpkg.json not found", file=sys.stderr) + sys.exit(1) +except json.JSONDecodeError as e: + print(f"Invalid JSON in vcpkg.json: {e}", file=sys.stderr) + sys.exit(1) +')
24-28: Consider filtering for release tag pattern.
git tag --containsreturns all tags (including potential non-release tags). vcpkg release tags follow a date pattern (e.g.,2024.01.12). Consider filtering to ensure only release tags are matched.♻️ Suggested filter
tags=$(git -C "${tmp_dir}" tag --contains "${baseline_sha}") +# Filter to release tags only (date pattern: YYYY.MM.DD) +release_tags=$(echo "${tags}" | grep -E '^[0-9]{4}\.[0-9]{2}\.[0-9]{2}$' || true) -if [[ -z "${tags}" ]]; then +if [[ -z "${release_tags}" ]]; then echo "builtin-baseline ${baseline_sha} is not contained in any microsoft/vcpkg release tag." >&2 exit 1 fi
11-13: Consider cleaning up temp directory on success.The
.tmp/vcpkg-tagsdirectory is created but not removed after successful verification. While CI runners are ephemeral, local runs will accumulate this directory.♻️ Add cleanup trap
tmp_dir=".tmp/vcpkg-tags" rm -rf "${tmp_dir}" mkdir -p "${tmp_dir}" +trap 'rm -rf "${tmp_dir}"' EXIT.github/workflows/update-vcpkg-release.yml (1)
17-24: Consider extracting tag resolution to a reusable composite action.The tag resolution logic is duplicated between
preview-vcpkg-update(lines 17-24) andupdate-vcpkg(lines 38-46). While acceptable for now, extracting to a composite action would improve maintainability if the logic needs updates.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/update-vcpkg-release.yml.github/workflows/verify-vcpkg-baseline.yml.gitmodulesCMakePresets.json.rejREADME.mdtools/verify-vcpkg-baseline-is-release.sh
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/verify-vcpkg-baseline.yml
- .gitmodules
🧰 Additional context used
🪛 actionlint (1.7.10)
.github/workflows/update-vcpkg-release.yml
67-67: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 YAMLlint (1.37.1)
.github/workflows/update-vcpkg-release.yml
[error] 67-67: syntax error: mapping values are not allowed here
(syntax)
🔇 Additional comments (2)
README.md (1)
520-526: LGTM!The vcpkg policy documentation is clear and accurately reflects the automated workflow and toolchain configuration introduced in this PR.
.github/workflows/update-vcpkg-release.yml (1)
29-31: Permissions are appropriately scoped.The workflow correctly declares minimal permissions (
contents: writeandpull-requests: write) needed for creating the PR.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
d1bc762 to
9e0fa39
Compare
Introduce GitHub Actions workflows to automate updating the vcpkg submodule and verifying that the vcpkg builtin-baseline is a release tag. Add a shell script for baseline verification, update the README with vcpkg policy, and add the vcpkg submodule configuration. Also include a rejected patch file for CMakePresets.json related to vcpkg toolchain path changes.
9e0fa39 to
18c38c8
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/update-vcpkg-release.yml:
- Around line 31-39: The current step only checks for .gitmodules file and can
miss a missing vcpkg entry; update the logic around the "Update vcpkg submodule
to latest release" step to explicitly detect the vcpkg submodule (e.g., check
for the path "external/vcpkg" via git submodule status external/vcpkg or by
grepping .gitmodules for the vcpkg path) and if it's missing run git submodule
add https://github.com/microsoft/vcpkg.git external/vcpkg, otherwise run git
submodule update --init --recursive or git submodule update --init
external/vcpkg before running git -C external/vcpkg fetch --tags origin and git
-C external/vcpkg checkout "${{ steps.vcpkg_tag.outputs.tag }}"; ensure the
detection is robust so subsequent fetch/checkout commands won't fail.
♻️ Duplicate comments (1)
.github/workflows/update-vcpkg-release.yml (1)
41-44: Note:x-update-baselineis experimental.This command may change or be removed in future vcpkg releases. The implementation is correct for current vcpkg versions.
🧹 Nitpick comments (3)
tools/verify-vcpkg-baseline-is-release.sh (2)
9-14: Missing error handling for vcpkg.json parsing.If
vcpkg.jsondoesn't exist or lacks thebuiltin-baselinekey, Python will raise an exception and the script will fail with a cryptic traceback rather than a user-friendly message. Consider adding explicit error handling.♻️ Suggested improvement
-baseline_sha=$("${python_bin}" -c 'import json; print(json.load(open("vcpkg.json"))["builtin-baseline"])') +baseline_sha=$("${python_bin}" -c 'import json,sys; d=json.load(open("vcpkg.json")); print(d.get("builtin-baseline",""))' 2>/dev/null) || { + echo "Failed to read builtin-baseline from vcpkg.json" >&2 + exit 1 +}
16-27: Consider adding error handling for fetch operations.If
baseline_shais a malformed or non-existent commit, line 27 will fail with a git error. Adding explicit validation would provide clearer feedback.♻️ Optional: wrap fetch in error handler
git -C "${tmp_dir}" fetch --tags origin -git -C "${tmp_dir}" fetch origin "${baseline_sha}" +if ! git -C "${tmp_dir}" fetch origin "${baseline_sha}" 2>/dev/null; then + echo "Failed to fetch baseline SHA ${baseline_sha} from vcpkg remote." >&2 + exit 1 +fi.github/workflows/verify-vcpkg-baseline.yml (1)
10-17: Consider removing the OS matrix.The verification script only performs git operations against the remote vcpkg repository and parses a local JSON file—neither operation is OS-dependent. Running on both Ubuntu and Windows doubles CI time without additional coverage value.
♻️ Simplified workflow (single runner)
jobs: verify-baseline: - runs-on: ${{ matrix.os }} - strategy: - matrix: - os: - - ubuntu-latest - - windows-latest + runs-on: ubuntu-latest steps:
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/update-vcpkg-release.yml.github/workflows/verify-vcpkg-baseline.yml.gitmodulesCMakePresets.json.rejREADME.mdtools/verify-vcpkg-baseline-is-release.sh
🚧 Files skipped from review as they are similar to previous changes (3)
- .gitmodules
- README.md
- CMakePresets.json.rej
🔇 Additional comments (8)
tools/verify-vcpkg-baseline-is-release.sh (3)
1-2: Shebang and strict mode are appropriate.Good use of
set -euo pipefailfor fail-fast behavior in CI scripts.
4-7: Python fallback logic is correct.The fallback from
python3topythonhandles environments where only one is available.
29-36: Tag containment verification is correct.The
git tag --containsapproach properly validates that the baseline SHA is reachable from at least one release tag..github/workflows/verify-vcpkg-baseline.yml (2)
1-9: Workflow triggers are appropriate.Running on pushes to main/master and on PRs ensures baseline verification on both direct commits and contributions.
18-26: Checkout configuration and script invocation are correct.Using
fetch-depth: 0andsubmodules: trueensures all required data is available for the verification script..github/workflows/update-vcpkg-release.yml (3)
1-6: Schedule and manual dispatch triggers are appropriate.Weekly Monday runs at 06:00 UTC with manual override capability is a good pattern for dependency updates.
46-60: PR creation configuration is correct.Proper permissions, branch naming convention, and labels for automated dependency PRs.
21-29: Concern about non-release tags is not applicable to vcpkg.The actual vcpkg tags follow a consistent release tag format (YYYY.MM.DD), with no non-release tags like
nightly-*,preview-*, etc. present in the repository. The current implementation usingsort -V | tail -n1correctly handles these tags, including edge cases like2022.06.16.1with patch versions. No changes are needed.Likely an incorrect or invalid review comment.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| - name: Update vcpkg submodule to latest release | ||
| run: | | ||
| if [[ ! -f .gitmodules ]]; then | ||
| git submodule add https://github.com/microsoft/vcpkg.git external/vcpkg | ||
| else | ||
| git submodule update --init --recursive | ||
| fi | ||
| git -C external/vcpkg fetch --tags origin | ||
| git -C external/vcpkg checkout "${{ steps.vcpkg_tag.outputs.tag }}" |
There was a problem hiding this comment.
Submodule initialization logic has an edge case.
The condition checks if .gitmodules exists, but doesn't verify the vcpkg entry is present. If .gitmodules exists with other submodules but vcpkg isn't defined, git submodule update --init won't initialize vcpkg, and subsequent commands will fail.
A more robust approach would check for the specific submodule entry or use git submodule status to determine state.
🐛 More robust submodule handling
- name: Update vcpkg submodule to latest release
run: |
- if [[ ! -f .gitmodules ]]; then
+ if ! grep -q '\[submodule "external/vcpkg"\]' .gitmodules 2>/dev/null; then
git submodule add https://github.com/microsoft/vcpkg.git external/vcpkg
else
git submodule update --init --recursive
fi
git -C external/vcpkg fetch --tags origin
git -C external/vcpkg checkout "${{ steps.vcpkg_tag.outputs.tag }}"🤖 Prompt for AI Agents
In @.github/workflows/update-vcpkg-release.yml around lines 31 - 39, The current
step only checks for .gitmodules file and can miss a missing vcpkg entry; update
the logic around the "Update vcpkg submodule to latest release" step to
explicitly detect the vcpkg submodule (e.g., check for the path "external/vcpkg"
via git submodule status external/vcpkg or by grepping .gitmodules for the vcpkg
path) and if it's missing run git submodule add
https://github.com/microsoft/vcpkg.git external/vcpkg, otherwise run git
submodule update --init --recursive or git submodule update --init
external/vcpkg before running git -C external/vcpkg fetch --tags origin and git
-C external/vcpkg checkout "${{ steps.vcpkg_tag.outputs.tag }}"; ensure the
detection is robust so subsequent fetch/checkout commands won't fail.
|
This PR is stale because it has been open 45 days with no activity. |
Introduce GitHub Actions workflows to automate updating the vcpkg submodule to the latest release and to verify that the vcpkg builtin-baseline is a release tag. Add a shell script for baseline verification, update the README with vcpkg policy, and add the vcpkg submodule configuration.
Summary by CodeRabbit
Chores
Tools
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.