Automated sync from private repo (2026-05-22)#722
Merged
foundry-samples-repo-sync[bot] merged 3 commits intoMay 22, 2026
Conversation
* Applied existng vnet fixes and added cleanup scripts for easy resource cleanup * Minor updates * remove deployment-tools from template fixes PR (will be separate PR)
* Add MAF RAG, Skills, Memory samples
* Remove auto generated files
* Fix tests
* Fix tests
* Narrow requirements.txt to direct subpackages
Replace the bare `agent-framework` meta-package in the requirements of the
new RAG, Skills and Memory samples (11/12/13) with the dedicated subpackages
those samples actually import:
- `agent-framework-foundry` (provides `Agent`, `SkillsProvider`,
`FoundryChatClient`, `FoundryMemoryProvider`, and pulls in
`azure-ai-projects` transitively for the SDK clients used by the
bootstrap/provisioning scripts)
- `agent-framework-azure-ai-search` (sample 11 only — provides
`AzureAISearchContextProvider`)
- `agent-framework-foundry-hosting` (provides `ResponsesHostServer`)
- `azure-ai-projects` kept explicit on 12 and 13 because their
`main.py` / provisioning scripts import `azure.ai.projects` directly.
The bare `agent-framework` package requires `agent-framework-core[all]`,
which on Linux x86_64 (the `python:3.12-slim` container build) activates
the full optional dependency set including `agent-framework-hyperlight`
and its native `hyperlight-sandbox-backend-wasm` wheel. This wide
dependency surface caused the `pip install -r requirements.txt` step for
sample 12 to fail with `ResolutionImpossible` in the Hosted Agents
Foundry Extension E2E pipeline. Narrowing each sample's requirements to
the subpackages whose APIs it actually uses cuts the transitive install
from ~100 packages to ~30, removes the platform-specific wheels, and
follows the upstream "selective install" recipe documented in the
`agent-framework` README.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Treat un-substituted env-var placeholders as unset
The Foundry Ext E2E pipeline drives the Foundry VS Code extension to
deploy each sample without exporting the optional environment variables
the new RAG / Skills / Memory samples reference in their `agent.yaml`
(`AZURE_SEARCH_ENDPOINT`, `AZURE_SEARCH_INDEX_NAME`, `SKILL_NAMES`,
`MEMORY_STORE_NAME`). The extension's deploy-time substitution leaves
those references as literal `${VAR}` text on the running container
rather than empty strings, which breaks the samples' existing
"is the env var set?" checks:
- Sample 11 (`azure-search-rag`) constructs an
`AzureAISearchContextProvider` with the literal `${AZURE_SEARCH_ENDPOINT}`
endpoint. The container starts (`/readiness` passes) but every
Responses request fails with `server_error: An internal server error
occurred.` once the search call is made — observed as 43 retry
attempts in the Foundry Ext E2E smoke test.
- Sample 12 (`foundry-skills`) splits `${SKILL_NAMES}` into a single
non-empty entry and tries to download a skill named `${SKILL_NAMES}`
from the Foundry `beta.skills` API at startup. The download
exception crashes `main()` before `ResponsesHostServer.run_async()`
binds `/readiness`, so every smoke request returns
`424 session_not_ready`.
- Sample 13 (`foundry-memory`) currently survives the same situation
because `FoundryMemoryProvider` happens to tolerate a bogus
`memory_store_name` at query time, but the same latent bug is there.
Add a small `_resolved_env` helper to each sample that treats both
`${VAR}` and `{{VAR}}` template placeholders (as well as missing
and empty values) as "unset". The provider/bootstrap branch only runs
when the value is a real, substituted string, so the agent starts
cleanly and responds without the optional capability when those
resources aren't provisioned. The helper is intentionally duplicated
per sample so each sample remains self-contained.
For sample 12, also bound `_bootstrap_skills` with
`asyncio.wait_for(..., timeout=60)` so a slow or hung Foundry
`beta.skills` round-trip can't keep `/readiness` from returning 200
past the hosted-agent runtime's session-readiness timeout window.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Force JSON output from `azd ai agent show` in Cloud E2E
The recent `azd` CLI release changed `azd ai agent show --no-prompt`'s
default output from JSON to a human-readable two-column table, which
makes the `jq` filter on the responses-endpoint lookup fail with
`Invalid numeric literal at line 1, column 6` and abort every
responses-protocol invoke step with
`Could not resolve agent responses endpoint from 'azd ai agent show'`.
This has been failing on the `main` branch since 2026-05-18 and affects
all hosted-agent samples (the unchanged 10-downstream-azure sample fails
identically alongside the new 11/12/13 samples).
Pass `--output json` explicitly so `jq` gets the structure it expects.
This is the same flag the cleanup step on line 840 of this workflow
already uses for the same command.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add test-payload.txt for samples 11, 12, 13
Provide per-sample Cloud E2E invoke prompts that exercise each new
sample's actual scenario, matching the convention used by samples
07-skills and 09-declarative-customer-support.
- 11-azure-search-rag: three retrieval prompts that target the
return-policy, shipping-guide and tent-care documents seeded by
provision_index.py, so a configured deployment can verify the
RAG context provider actually pulled the indexed content.
- 12-foundry-skills: three customer-support prompts, including one
injury+legal-action scenario that should trigger the
escalation-policy skill, so a configured deployment can verify both
the support-style voice and the escalation flow.
- 13-foundry-memory: three turns that share two user facts in turns
1-2 and ask the agent to recall them in turn 3, so a configured
deployment can verify the memory provider stored and retrieved the
facts across the conversation.
Without the optional env vars set (the current CI environment) the
agent still answers each prompt using just the LLM, so these payloads
are also safe for runs that don't provision the search index / skills
/ memory store.
Addresses review feedback from ankitbko on PR #320.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Ed van Bruggen <edvan@github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: eavanvalkenburg <github@vanvalkenburg.eu>
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
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.
Automated sync from private repo.
Synced commits: 3
Authors: Hui Miao,Mahya Gheini Tao Chen
Validation gate: mode=
none; tracked=17; blocked=0.Rollback point:
91a02c7ea64ebec4c4ebd94e495e3d6a5f413d6a— to revert, force-push this SHA tomainand clear the sync-marks cache.Triggered by:
scheduleRun: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/26274124744