You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-developer-cli/azd-extensibility.md
+55-2Lines changed: 55 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.service: azure-dev-cli
11
11
12
12
# Customize your Azure Developer CLI workflows using command and event hooks
13
13
14
-
The Azure Developer CLI supports various extension points to customize your workflows and deployments. The hooks middleware allows you to execute custom scripts before and after `azd` commands and service lifecycle events. hooks follow a naming convention using *pre* and *post* prefixes on the matching `azd` command or service event name.
14
+
Hooks are `azd`extension points that automatically execute custom scripts before and after `azd` commands and service lifecycle events. Hooks follow a naming convention using *pre* and *post* prefixes on the matching `azd` command or service event name.
15
15
16
16
For example, you may want to run a custom script in the following scenarios:
17
17
@@ -38,7 +38,7 @@ The following service lifecycle event hooks are available:
38
38
39
39
## Hook configuration
40
40
41
-
Hooks can be registered in your `azure.yaml` file at the root or within a specific service configuration. All types of hooks support the following configuration options:
41
+
Hooks are registered in your `azure.yaml` file at the root or within a specific service configuration. All types of hooks support the following configuration options:
42
42
43
43
*`shell`: `sh` | `pwsh`
44
44
**Note*: PowerShell 7 is required for `pwsh`.
@@ -161,6 +161,59 @@ hooks:
161
161
run: scripts/postprovision2.sh
162
162
```
163
163
164
+
## Run hooks independently
165
+
166
+
The `azd hooks run` command allows you to execute hooks independently of their normal trigger events. This is useful for testing and debugging hooks without going through the entire workflow.
167
+
168
+
```bash
169
+
azd hooks run <hook-name>
170
+
```
171
+
172
+
Replace `<hook-name>` with the name of the hook you want to run (e.g., `preprovision`, `postdeploy`).
173
+
174
+
### Advanced options
175
+
176
+
```bash
177
+
# Run a specific service hook
178
+
azd hooks run postdeploy --service api
179
+
180
+
# Force hooks to run for a specific platform
181
+
azd hooks run preprovision --platform windows
182
+
183
+
# Run hooks in a specific environment
184
+
azd hooks run postup -e staging
185
+
186
+
# Run hooks with all options combined
187
+
azd hooks run predeploy --service frontend --platform posix -e production --interactive
188
+
```
189
+
190
+
## Configure interactive mode
191
+
192
+
Hooks run in interactive mode by default. Interactive hooks mode allows you to run hook scripts with direct console interaction, making it easier to debug, monitor, and interact with your hooks in real-time. You can explicitly set the `interactive` property in your hook configuration if you want to disable interactive mode for a specific hook:
193
+
194
+
```yaml
195
+
hooks:
196
+
postprovision:
197
+
shell: sh
198
+
run: ./scripts/setup-database.sh
199
+
interactive: false # Default is true
200
+
```
201
+
202
+
For service-specific hooks:
203
+
204
+
```yaml
205
+
services:
206
+
api:
207
+
project: ./src/api
208
+
language: js
209
+
host: appservice
210
+
hooks:
211
+
postdeploy:
212
+
shell: sh
213
+
run: ./scripts/post-deploy-verification.sh
214
+
interactive: false # Override the default interactive mode
215
+
```
216
+
164
217
### Use environment variables with hooks
165
218
166
219
Hooks can get and set environment variables in the `.env` file using the `azd env get-values` and `azd set <key> <value>` commands. Hooks can also retrieve environment variables from your local environment using the `${YOUR_ENVIRONMENT VARIABLE}` syntax. `azd` automatically sets certain environment variables in the `.env` file when commands are run, such as `AZURE_ENV_NAME` and `AZURE_LOCATION`. Output parameters from the `main.bicep` file are also set in the `.env` file. The [manage environment variables](/azure/developer/azure-developer-cli/manage-environment-variables) page includes more information about environment variable workflows.
Copy file name to clipboardExpand all lines: articles/azure-developer-cli/azd-init-workflow.md
+43-3Lines changed: 43 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,7 +107,7 @@ You can also use the initialized template as a starting point for further develo
107
107
108
108
For advanced users who want to start with a minimal setup and customize everything manually, this option provides just the essential configuration.
109
109
110
-
1. Run the `azd init` command:
110
+
1. Run the `azd init`command with the `--minimal` flag:
111
111
112
112
```bash
113
113
azd init --minimal
@@ -124,9 +124,49 @@ For advanced users who want to start with a minimal setup and customize everythi
124
124
Run azd add to add new Azure components to your project.
125
125
```
126
126
127
-
Only the essential `azure.yaml` configuration file is created. No application code or comprehensive infrastructure templates are added, so you need to manually create or customize the infrastructure files based on your requirements.
127
+
The `--minimal` flag creates only the following:
128
+
129
+
- A basic `azure.yaml` file with just the project name and schemaVersion
130
+
- A `.azure` directory for environment configuration
131
+
- A `.gitignore` file with appropriate entries for Azure Developer CLI
132
+
133
+
This streamlined initialization is ideal when you:
134
+
135
+
- Want to build your infrastructure from scratch
136
+
- Need to integrate `azd` with an existing complex project
137
+
- Plan to use the `azd add`command to incrementally build your architecture
138
+
- Prefer full control over your project structure
139
+
140
+
3. After initialization, you can:
141
+
- Manually create your infrastructure files in an `infra` folder
142
+
- Use the `azd add` [compose feature](azd-compose.md) to start adding Azure resources to your app
143
+
- Customize your `azure.yaml` file to define your services and resources
144
+
145
+
## Project and Azure resource naming
146
+
147
+
When you initialize a new or existing project, the project name is setin`azure.yaml`. The project name acts as a prefix for Azure resource names created during the provisioning process. By adhering to the validation rules, you ensure that generated Azure resource names will also be valid.
148
+
149
+
In Bicep or Terraform templates, the project name is often used as a base for constructing resource names, combined with the environment name and other elements. For example:
150
+
151
+
```bicep
152
+
var resourceToken = '${name}-${environmentName}'
153
+
```
154
+
155
+
Where `name` refers to the project name and `environmentName` is the name of your `azd` environment.
156
+
157
+
## Project name validation rules
158
+
159
+
When using `azd init` to initialize a project or when creating a new project name in the `azure.yaml` file, the following validation rules are applied:
160
+
161
+
| Rule | Description |
162
+
|------|-------------|
163
+
| Allowed characters | Project names can include lowercase letters, numbers, and hyphens only. |
164
+
| Starting character | Project names must start with a letter. |
165
+
| Ending character | Project names must not end with a hyphen. |
166
+
| Length | Project names must be between 2 and 63 characters long. |
3. Optionally, use the `azd add` [compose feature](azd-compose.md) to start adding Azure resources to your app.
169
+
These validation rules ensure that your project name will be compatible with the naming requirements of Azure resources and prevent service packaging failures during deployment.
0 commit comments