Python: Move all FHA samples to azure.yaml #7250

Activity

1. Tao Chen (TaoChenOSU)

   self-assigned this

   on Jul 22, 2026
2. Tao Chen (TaoChenOSU)

   added

   pythonUsage: [Issues, PRs], Target: PythonUsage: [Issues, PRs], Target: Python

   foundryUsage: [Issues, PRs], Target: all Foundry integrationsUsage: [Issues, PRs], Target: all Foundry integrations

   hostingUsage: [Issues, PRs], Target: all hosting related solutionsUsage: [Issues, PRs], Target: all hosting related solutions

   on Jul 22, 2026
3. Tao Chen (TaoChenOSU)

   changed the issue type from

   Feature

   to

   Task

   on Jul 22, 2026
4. Tao Chen (TaoChenOSU)

   added the

   Feature

   issue type on Jul 22, 2026
5. github-project-automation

   added this to Agent Frameworkon Jul 22, 2026
6. github-actions

   changed the title [-][Feature]: Move all FHA samples to azure.yaml[/-] [+]Python: [Feature]: Move all FHA samples to azure.yaml[/+] on Jul 22, 2026
7. Tao Chen (TaoChenOSU)

   changed the title [-]Python: [Feature]: Move all FHA samples to azure.yaml[/-] [+]Python: Move all FHA samples to azure.yaml[/+] on Jul 22, 2026
8. eavanvalkenburg commented on Oct 28, 2026

   

   Eduard van Valkenburg (eavanvalkenburg)

   on Oct 28, 2026

   Member

   More actions

   /plan Plan the remaining Python Foundry hosted-sample migration to unified azure.yaml and .azdignore, coordinating existing work rather than starting a parallel implementation.

   Current main still has legacy agent.yaml/agent.manifest.yaml pairs across most Responses and Invocations samples. Telegram already has azure.yaml, and only some samples have .azdignore. The current authoring guidance confirms the unified project/service structure:
   https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/author-azure-yaml

   Use open #9402 as the existing basic-sample/template-command migration pilot. Coordinate overlapping configuration/startup guidance with open #9643 without treating its proposed startup default as already accepted. Closed, unmerged #9560 is prior Toolbox migration investigation, not a completed migration or approved implementation to reopen.

   Please produce a sample-by-sample migration/checklist that:

   • Establishes the supported azd/Foundry-extension versions and code-versus-container deployment paths, then maps each sample's actual project, agent, model, connection, toolbox, environment and protocol settings into the unified service dependency graph. Do not copy one generic configuration across samples with different resource needs.
   • Keeps each sample independently initializable from this repository, preserves required runtime assets and request-owned identity/resource behavior, and explicitly identifies unsupported runtime requirements rather than implying universal deployability.
   • Adds appropriate .azdignore rules without excluding required source/configuration assets or uploading secrets, local environments or azd state. Retires legacy files only when their references, CLI commands and documented entry paths have replacements.
   • Updates directly related READMEs, shared instructions, validation harness assumptions and maintained Python consumer hosting guidance consistently. Identify external service/CLI blockers separately from repository work.
   • Defines offline schema/reference/configuration checks and a representative local/cloud validation matrix across Responses, Invocations, workflows and dependency-heavy Toolbox/RAG scenarios. Record required credentials, quota and cleanup, and distinguish planned validation from results actually obtained.

   This is accepted repository sample/configuration maintenance, not a minor production-code ticket. Preserve the current owner and do not mark ready, assign volunteers, close/reopen PRs, provision Azure resources, or promise deployment compatibility merely because this plan was requested.

   👀React with 👀1Reacted by github-actions