Skip to content
Open
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
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,7 @@ All recipes should use these shared patterns:
| [UAMI Bindings](common/uami-bindings.md) | `common/uami-bindings.md` | **MANDATORY** — App settings for managed identity connections |
| [Error Handling](common/error-handling.md) | `common/error-handling.md` | Try/catch + logging patterns per language |
| [Health Check](common/health-check.md) | `common/health-check.md` | Health endpoint for monitoring/load balancers |
| [Post-Generation](common/post-generation.md) | `common/post-generation.md` | **MANDATORY** — File naming, README updates, test scaffolding |

## Available Recipes

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,119 @@
# Post-Generation Updates

> **MANDATORY**: After creating or adding any Azure Function, perform these three steps.

## 1. File Naming Convention

Name function source files after their **route or purpose**, not the generic trigger type.

| Route / Purpose | ✅ Correct filename | ❌ Avoid |
|-----------------|---------------------|---------|
| `/api/random` | `src/functions/random.js` | `httpTrigger.js` |
| `/api/users` | `src/functions/users.js` | `httpTrigger.js` |
| `/api/health` | `src/functions/health.js` | `httpTrigger.js` |
| Cosmos DB change feed | `src/functions/cosmosProcessor.js` | `function1.js` |
| Scheduled job | `src/functions/dailyReport.js` | `timerTrigger.js` |

**Rules:**
- Derive the name from the route segment (e.g., `/api/random` → `random`) or the purpose (e.g., `dailyReport`)
- Use camelCase for multi-word names (e.g., `userProfile.js`, `orderProcessor.js`)
- Trigger-type suffixes are optional; prefer the shortest descriptive name
- Do **not** use generic names like `httpTrigger`, `function1`, or `index` unless unavoidable

## 2. README Update

After adding a new function, update (or create) the project's `README.md`:

1. **Add to endpoints table** – include function name, route, method, auth level, and description
2. **Add curl example** – provide a ready-to-run `curl` command for local and deployed testing
3. **Document env variables** – list any new environment variables the function requires

### Template

````markdown
## Available Endpoints

| Function | Route | Method | Auth | Description |
|----------|-------|--------|------|-------------|
| `<functionName>` | `/api/<route>` | GET/POST | anonymous/function | <description> |

### Test locally

```bash
curl http://localhost:7071/api/<route>
```

### Test deployed

```bash
curl https://<functionapp>.azurewebsites.net/api/<route>
```
````

### Example (route `/api/random`)

````markdown
## Available Endpoints

| Function | Route | Method | Auth | Description |
|----------|-------|--------|------|-------------|
| `random` | `/api/random` | GET | anonymous | Returns a random number |

### Test locally
Copy link
Contributor

Choose a reason for hiding this comment

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

Adding tests is a great way to build confidence in the changes made. Is there a reason why .http files are chosen? Is it for the user to validate the changes/ update the test suite like unit/ integration testing? or is it for the skill to validate if deployed route is functioning?


```bash
curl http://localhost:7071/api/random
```

### Test deployed

```bash
curl https://<functionapp>.azurewebsites.net/api/random
```
````

## 3. Test File Updates

After adding a new function, update the project's test files.

### If a `test.http` file exists

Append a request block for the new function:

```http
### <FunctionName> - local
GET http://localhost:7071/api/<route>

### <FunctionName> - deployed
GET https://{{functionAppName}}.azurewebsites.net/api/<route>
```

For POST endpoints, include a body:

```http
### <FunctionName> POST - local
POST http://localhost:7071/api/<route>
Content-Type: application/json

{
"key": "value"
}
```

### If a `testdata.json` (or similar data file used with curl) exists

Append an entry for the new function's expected input/output:

```json
{
"<functionName>": {
"route": "/api/<route>",
"method": "GET",
"expectedStatus": 200
}
}
```

### If neither `test.http` nor a testdata file exists

Create a `test.http` file at the project root with a request block for the new function (see template above).
Comment on lines +117 to +119
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

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

Inconsistency with composition.md Step 5.5: This section says to create a new test.http file when none exists, but composition.md line 168 says to "add a TODO comment in README.md" in that scenario. These two guidance documents should provide the same instruction. Consider aligning them - either always create test.http (more proactive) or always add a TODO comment (less prescriptive).

Copilot uses AI. Check for mistakes.
Loading