Bump to 1.0.0b10#493
Closed
JC-386 wants to merge 21 commits into
Closed
Conversation
* Bump hosted agents version to 1.0.0b8 * remove agent_framework dependency in requrements.txt * add a sample for agentframework with foundry tool * align naming convention --------- Co-authored-by: junanchen <junanchen@microsoft.com>
* use latest from_agent_framework signature * remove keyword
* add lg tools sample, bump agentserver version to 1.0.0b9 * rename FoundryToolsReactAgent * add desc FoundryToolsReactAgent
Mengla/fix_cx_readme
Mengla/add_samples_gated_test
Melionel/fix-unittest
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
JC-386
had a problem deploying
to
hosted-agents-test
GitHub Actions
Failure
vtrika
pushed a commit
to vtrika/foundry-samples
that referenced
this pull request
Jun 11, 2026
…icrosoft-foundry#493) * Fix protected-paths guard to use merge-tree simulation (ADO 5347121) `guard_protected_paths()` in `.github/scripts/sync-core.sh` previously compared blobs at `sync_branch_tip:<path>` against `public_main:<path>`. Because `git fast-export --import-marks` combined with pathspec filters forces `--full-tree` mode, every emitted commit becomes a `deleteall` plus one `M` record per included file -- so excluded paths (`.github/`) are absent from the sync-branch-tip tree even when the eventual rebase-merge into public main would preserve them unchanged. The result: once a protected workflow file exists on public main, the guard hard-fails every incremental sync regardless of whether the merge would actually disturb the file. Scheduled sync has been paused since 2026-06-08. This change replaces the blob comparison with a `git merge-tree --write-tree` simulation. The guard now computes the prospective post-rebase-merge tree from public `origin/main` and the sync branch, then compares the public-main blob against the merged-tree blob for each protected path. Both topologies are correctly classified: * Normal incremental sync (`--import-marks` parent chain anchors to previous sync-import commits that also lacked `.github/`): the 3-way merge preserves `.github/` from public main, so the result tree has the unchanged blob and the guard passes. * Seed-marks recovery (parent chain anchors to public_sha that HAS `.github/`): the new sync commit's parent tree contains `.github/` while its own tree does not -- a real delete in the rebase-merge. The result tree omits the protected file and the guard correctly hard-fails with the existing "MISSING from sync branch" error. Non-zero exit from `merge-tree` is surfaced via a distinct conflict error so real prospective-merge conflicts are not conflated with protected-paths violations. For the synthetic true-orphan case (no common ancestor; only test fixtures hit this in practice), the guard falls back to the sync-branch tree directly, preserving orphan-wipe detection -- explicitly NOT using `--allow-unrelated-histories`, which empirically produces a UNION tree that would silently false-pass orphan wipes. Requires git >= 2.38 for `merge-tree --write-tree`. GitHub-hosted CI runners (ubuntu-latest) are at 2.43+. The guard validates the git version up front and fails loudly with a useful message if it is too old. GitHub's actual sync-PR merge strategy (`gh pr merge --rebase` with `--squash` fallback) produces the same protected-path blob set as a 3-way merge from `merge-tree`'s perspective, so the simulation is sound for either path. Tests (from PR microsoft-foundry#492 which landed the failing reproducer): T64-T68 guard unit tests on synthesized branches PASS (unchanged) T69 normal incremental + protected file RED -> GREEN T70 seed-recovery wipe (regression coverage) PASS (unchanged) Local test summary (WSL): Tests run: 75 | Passed: 66 | Failed: 9. The 9 failures (T29, T31, T32, T35, T36, T48, T50, T54, T55) are pre-existing environment-only issues (getcwd quirks, missing `jq`, verify-sync drift detection on the local fixture) that reproduce identically on `main` without this change. CI runners pass cleanly. Docs: `docs/repo-sync-automation.md` -- the "Known issue: guard incompatible with `fast-export --import-marks` + pathspec" section is removed; the Protected-paths guard intro and False-positive risk subsection are rewritten to describe the new merge-tree semantics; a 2026-06-09 Changelog entry records the fix. The 2026-06-08 historical entry is updated only to drop a now-dead anchor link. Re-enabling the scheduled cron in `.github/workflows/sync-to-public.yml` is tracked separately as ADO 5347122 (post-CI-confirmation follow-up). Bug: https://msdata.visualstudio.com/Vienna/_workitems/edit/5347121 Repro PR (tests-first): microsoft-foundry/foundry-samples-pr#492 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Clarify divergent-content error message: "prospective merge result blob" The error message previously said "vs sync branch blob" but the blob being shown is from the prospective post-rebase-merge tree (`result_blob`), not the sync-branch-tip tree. Rephrase to match actual semantics and add an inline comment explaining the distinction. T67 only greps for the substring `divergent content` so the rename is safe. Addresses microsoft-foundry/foundry-samples-pr#493 (review). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
vtrika
pushed a commit
to vtrika/foundry-samples
that referenced
this pull request
Jun 11, 2026
…rosoft-foundry#499) Restores the nightly 06:00 UTC `schedule` block in `sync-to-public.yml` that PR microsoft-foundry#484 commented out on 2026-06-08. The guard bug that motivated the pause (ADO 5347121) was fixed by PR microsoft-foundry#493, and the 2026-06-09 recovery sequence (private PR microsoft-foundry#495 + public PR microsoft-foundry#767) was validated end-to-end by a successful `workflow_dispatch` real run: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/27253358355 Sync is operationally healthy again; the first scheduled run after merge will land at the next 06:00 UTC. Closes ADO 5347122. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.