Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 4 additions & 38 deletions .planning/ROADMAP.md
Original file line number Diff line number Diff line change
@@ -1,43 +1,9 @@
# Roadmap: CAS Reference Product

## Phase 1: Public v0.1 Reference Application
## Archived Milestones

**Goal:** Deliver a locally runnable, cloud-ready reference workload without deploying Azure resources.
- [x] [v0.1 Reference Application](milestones/v0.1-ROADMAP.md) — Delivered a locally runnable, cloud-ready reference workload without deploying Azure resources.

**Requirements:** API-01, AGENT-01, ID-01, CONTRACT-01, OBS-01, OPS-01, PLAT-01, QUAL-01, DOC-01
## Milestone v0.2

**Success criteria:**
- Local workflow request succeeds and returns canonical events.
- Tests, lint, type checks, and Docker build pass.
- Foundry mode uses Next Gen agent references and managed identity.
- Public documentation states deployment and security boundaries.

Status: Complete

## Phase 2: Telemetry Hardening

**Goal:** Wire OpenTelemetry end-to-end with lifecycle span events, W3C trace propagation, and Application Insights exporter.

**Requirements:** TEL-01, TEL-02, TEL-03, TEL-04

**Success criteria:**
- Every /api/v1/workflows request creates a `cas.api.workflows.execute` span with correlation_id, run_id, and intent attributes.
- Span events `workflow.started`, `workflow.completed`, and `workflow.failed` are emitted at the appropriate lifecycle points.
- W3C traceparent/tracestate headers on inbound requests are extracted and linked as parent context.
- Application Insights exporter activates when APPLICATIONINSIGHTS_CONNECTION_STRING is set; no-op otherwise.
- All telemetry behaviours verified by pytest with InMemorySpanExporter.

Status: Complete

## Phase 3: Docker + CI Publish

**Goal:** Containerize the app with a production-grade multi-stage Dockerfile and publish the image to GHCR on merge to main.

**Requirements:** DOCK-01, DOCK-02, DOCK-03

**Success criteria:**
- Multi-stage Dockerfile builds a linux/amd64 image, runs as non-root `appuser`, exposes port 8080, and health-checks via /health/ready.
- docker-compose.yml starts the local dev stack with env stubs using .env.example.
- CI docker job builds, smoke-tests (/health/live + /health/ready), and on push to main pushes to ghcr.io/coding-autopilot-system/cas-reference-product.

Status: Complete
*To be defined via /gsd-new-milestone*
File renamed without changes.
43 changes: 43 additions & 0 deletions .planning/milestones/v0.1-ROADMAP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Roadmap: CAS Reference Product

## Phase 1: Public v0.1 Reference Application

**Goal:** Deliver a locally runnable, cloud-ready reference workload without deploying Azure resources.

**Requirements:** API-01, AGENT-01, ID-01, CONTRACT-01, OBS-01, OPS-01, PLAT-01, QUAL-01, DOC-01

**Success criteria:**
- Local workflow request succeeds and returns canonical events.
- Tests, lint, type checks, and Docker build pass.
- Foundry mode uses Next Gen agent references and managed identity.
- Public documentation states deployment and security boundaries.

Status: Complete

## Phase 2: Telemetry Hardening

**Goal:** Wire OpenTelemetry end-to-end with lifecycle span events, W3C trace propagation, and Application Insights exporter.

**Requirements:** TEL-01, TEL-02, TEL-03, TEL-04

**Success criteria:**
- Every /api/v1/workflows request creates a `cas.api.workflows.execute` span with correlation_id, run_id, and intent attributes.
- Span events `workflow.started`, `workflow.completed`, and `workflow.failed` are emitted at the appropriate lifecycle points.
- W3C traceparent/tracestate headers on inbound requests are extracted and linked as parent context.
- Application Insights exporter activates when APPLICATIONINSIGHTS_CONNECTION_STRING is set; no-op otherwise.
- All telemetry behaviours verified by pytest with InMemorySpanExporter.

Status: Complete

## Phase 3: Docker + CI Publish

**Goal:** Containerize the app with a production-grade multi-stage Dockerfile and publish the image to GHCR on merge to main.

**Requirements:** DOCK-01, DOCK-02, DOCK-03

**Success criteria:**
- Multi-stage Dockerfile builds a linux/amd64 image, runs as non-root `appuser`, exposes port 8080, and health-checks via /health/ready.
- docker-compose.yml starts the local dev stack with env stubs using .env.example.
- CI docker job builds, smoke-tests (/health/live + /health/ready), and on push to main pushes to ghcr.io/coding-autopilot-system/cas-reference-product.

Status: Complete
30 changes: 29 additions & 1 deletion infra/modules/function-ingress.bicep
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,6 @@ resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
httpsOnly: true
publicNetworkAccess: 'Enabled'
siteConfig: {
linuxFxVersion: 'Python|3.12'
minTlsVersion: '1.2'
ftpsState: 'Disabled'
appSettings: [
Expand All @@ -36,6 +35,25 @@ resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
{ name: 'APPLICATIONINSIGHTS_CONNECTION_STRING', value: applicationInsightsConnectionString }
]
}
functionAppConfig: {
deployment: {
storage: {
type: 'blobContainer'
value: 'https://${storageAccountName}.blob.${environment().suffixes.storage}/app-package'
Comment on lines +38 to +42

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Configure host storage for Flex apps

When this Flex Consumption template is deployed, the new functionAppConfig only defines the code package container; the app settings still never define the required AzureWebJobsStorage/AzureWebJobsStorage__* host-storage connection. Because the storage account disables shared-key access, the Functions host has neither a connection string nor an identity-based host storage configuration, so the deployed function app won't be able to start reliably or serve the ingress function after rollout. Add the host storage app setting(s) and the matching storage RBAC for that connection.

Useful? React with 👍 / 👎.

authentication: {
type: 'SystemAssignedIdentity'
}
}
}
scaleAndConcurrency: {
maximumInstanceCount: 100
instanceMemoryMB: 2048
}
runtime: {
name: 'python'
version: '3.12'
}
}
}
}

Expand All @@ -53,5 +71,15 @@ resource queueContributor 'Microsoft.Authorization/roleAssignments@2022-04-01' =
}
}

resource blobContributor 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(storageAccountId, functionApp.id, 'blob-contributor')
scope: storageAccount
properties: {
principalId: functionApp.identity.principalId
principalType: 'ServicePrincipal'
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')
}
}

output id string = functionApp.id
output principalId string = functionApp.identity.principalId
10 changes: 10 additions & 0 deletions infra/modules/storage.bicep
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,16 @@ resource workQueue 'Microsoft.Storage/storageAccounts/queueServices/queues@2023-
name: 'cas-work-items'
}

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-05-01' = {
parent: account
name: 'default'
}

resource deploymentContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-05-01' = {
parent: blobService
name: 'app-package'
}

output id string = account.id
output name string = account.name
output queueName string = workQueue.name