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
### Named value secrets (with pipeline token substitution)
135
+
136
+
Secrets can be stored in Key Vault (see [Key Vault pattern](#key-vault-pattern) below) or injected at pipeline runtime using [token substitution](token-substitution.md). With token substitution, the `{#[TOKEN_NAME]#}` placeholder is replaced with the actual secret value from your pipeline's secret store (GitHub Actions Secrets or Azure DevOps variable groups).
137
+
138
+
```yaml
139
+
namedValues:
140
+
- name: payment-api-key
141
+
properties:
142
+
displayName: payment-api-key
143
+
secret: true
144
+
value: "{#[PAYMENT_API_KEY]#}" # Replaced at pipeline runtime
145
+
- name: webhook-secret
146
+
properties:
147
+
secret: true
148
+
value: "{#[WEBHOOK_SECRET]#}"
149
+
```
150
+
151
+
Store the actual secret values in:
152
+
- **GitHub Actions:** Environment secrets (Settings → Environments → Add secret). See [Using secrets in GitHub Actions](https://docs.github.com/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-an-environment).
153
+
- **Azure DevOps:** Variable groups marked as secret (Pipelines → Library). See [Use variable groups in pipelines](https://learn.microsoft.com/azure/devops/pipelines/library/variable-groups) and [Set secret variables](https://learn.microsoft.com/azure/devops/pipelines/process/set-secret-variables).
154
+
155
+
See the [Token Substitution guide](token-substitution.md) for complete setup instructions.
156
+
130
157
### Backends
131
158
132
159
```yaml
@@ -241,6 +268,8 @@ loggers:
241
268
isBuffered: true
242
269
```
243
270
271
+
> **Tip:** You can also use [pipeline token substitution](token-substitution.md) for logger credentials. Replace the hardcoded value with a placeholder like `{#[APPINSIGHTS_KEY]#}`, and store the actual key in your pipeline's secret store. This keeps secrets out of your repository entirely.
272
+
244
273
### Subscriptions
245
274
246
275
```yaml
@@ -298,7 +327,7 @@ policies:
298
327
299
328
### Version sets, groups, and tags
300
329
301
-
Overrides are also supported for `versionSets`, `groups`, `tags`, and `workspaces`. Each uses the same `name` + `properties` format:
330
+
Overrides are also supported for `versionSets`, `groups`, and `tags`. Each uses the same `name` + `properties` format:
302
331
303
332
```yaml
304
333
versionSets:
@@ -318,6 +347,50 @@ tags:
318
347
displayName: "Public API"
319
348
```
320
349
350
+
### Workspaces
351
+
352
+
Workspaces (Premium/StandardV2/PremiumV2 tiers) support overrides for the workspace container itself:
353
+
354
+
```yaml
355
+
workspaces:
356
+
- name: partner-workspace
357
+
properties:
358
+
displayName: "Partner Workspace (Production)"
359
+
description: "Production workspace for partner APIs"
360
+
```
361
+
362
+
#### Workspace-scoped resource overrides
363
+
364
+
Resources inside a workspace are extracted to `workspaces/<workspace-name>/` subdirectories. To override them, **nest** the child sections directly under the workspace entry (matching the APIOps Toolkit format):
The supported workspace child sections are: `apis`, `backends`, `diagnostics`, `groups`, `loggers`, `namedValues`, `policyFragments`, `products`, `subscriptions`, `tags`, and `versionSets`.
391
+
392
+
> ⚠️ **Known limitation — tracked in [#118](https://github.com/Azure/apiops-cli/issues/118):** workspace child overrides are *parsed* (the YAML above is accepted with no errors) but are **not yet applied at publish time**. Until #118 is fixed, only the workspace container's own `properties` are honored for workspace-scoped resources. Authoring overrides in this nested shape today is safe and forward-compatible — they will start taking effect automatically once the merger is updated.
0 commit comments