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
(SCHEMA) Enhance docs and validation for secret in extension manifest schema
This change makes some corrections to the documentation for the `secret` field
in the extension manifest schema:
- Moves the documentation about the capability contract from `secret.executable`
up to `secret`.
- Redefines the documentation for `secret.executable` to indicate defining the
path to an executable file.
- Rewrites the documentation for `secret.args` to clarify the requirement to
define a secret name input argument exactly once and the implications of not
defining the vault input argument. The new documentation also shows examples
of manifest snippets and the effective invocation.
- Adds annotation keywords to document the various valid argument types.
This change makes enhancements to the validation for the `secret` field:
- It makes `args` required, even though it isn't required in the schema for
the struct, because there's no functional way to pass the name of a secret
to the extension without defining a secret name input argument.
In `process_secret_args`, DSC considers it valid to define `secret` without
any arguments and without the secret name input argument, but doing so
means the extension is never sent the name of the secret to retrieve. The
same is true for manifests that don't define the vault input argument,
though conceivably an extension could be implemented without support for
retrieving secrets from a named vault.
https://github.com/PowerShell/DSC/blob/4750f779ecb27eb480f7ab37b8e8a526ed5054f5/dsc_lib/src/extensions/secret.rs#L108-L134
- It changes the `anyOf` in `secret.args.items` to `oneOf`, which is more
strictly correct. An item must be _either_ a string argument _or_ a secret
name input argument _or_ a vault input argument.
- It ensures that the minimum length for a defined argument is `1`, preventing
the accidental defining of an empty string. Arguably, we should also use the
`pattern` keyword to forbid spacing characters, but this change doesn't add
that stricter validation.
- Replaces usage of `additionalProperties` with `unevaluatedProperties` to
better support integrating tools and schema extensions.
- Adds the `allOf` keyword to the top level of `secret` to provide validation
for defining the correct number of secret name input arguments and vault
name input arguments. The author must define exactly one secret name input
argument in `secret.args` and zero or one vault input argument. The subschemas
use the VS Code extended vocabulary keyword `errorMessage` to provide specific
messaging when an author defines too few or too many of the secret name input
argument and too many of the vault input argument.
Finally, this change also updates the default snippets to remove the invalid
snippets, which didn't define the secret name input argument, and to reword
the documentation for those snippets. It also corrects the numbering of the
snippet placeholders.
Defines the literal string for the argument that accepts the name of the vault to
207
+
retrieve a secret from, like `--vault` or `--vault-name`.
208
+
markdownDescription: |-
209
+
Defines the literal string for the argument that accepts the name of the vault to
210
+
retrieve a secret from, like `--vault` or `--vault-name`.
111
211
type: string
212
+
minLength: 1
213
+
214
+
# Need to use an allOf with multiple possibilities to capture the requirement to define the secret
215
+
# name input argument exactly once and the vault input argument no more than once. Note that
216
+
# the YAML language server in VS Code currently doesn't understand the `minContains` and
217
+
# `maxContains` keywords, so when defining the extension manifest in YAML with the schema, the
218
+
# language server identifies the vault input argument as required. When defining the extension
219
+
# manifest in JSON, the language server correctly identifies the minimum and maximum number of
220
+
# arguments to use.
221
+
#
222
+
# Unfortunately, because we only get one error message per item in the `allOf` keyword, we have to
223
+
# define two entries for the secret name input argument to provide better validation error messages.
224
+
#
225
+
# We use long lines for error messages, which can't use Markdown, so line breaks are literal.
226
+
allOf:
227
+
- title: Missing secret name input argument
228
+
$comment: >-
229
+
This validation subschema ensures that `secret.args` contains a secret name input argument.
230
+
Without this argument, DSC can't pass the name of the secret to retrieve when invoking the
231
+
extension's secret command.
232
+
233
+
We define this separately from the maximum contains validation subschema to improve the error
234
+
messaging in VS Code.
235
+
properties:
236
+
args:
237
+
errorMessage: |-
238
+
The `secret` command doesn't define the secret name input argument. If you don't define the secret name input argument, DSC can't pass the secret name to the extension for retrieval. You can only define one secret name input argument for the command.
239
+
240
+
You must define one argument in `secret.args` as a JSON object with the `nameArg` property. For more information, see:
This validation subschema ensures that `secret.args` doesn't contain more than one secret
250
+
name input argument. Defining more than one secret name input argument is invalid.
251
+
252
+
We define this separately from the minimum contains validation subschema to improve the error
253
+
messaging in VS Code.
254
+
properties:
255
+
args:
256
+
errorMessage: |-
257
+
The `secret` command defines the secret name input argument more than once. You can only define one secret name input argument for the command.
258
+
259
+
You must define one argument in `secret.args` as a JSON object with the `nameArg` property and remove the additional secret name input arguments. For more information, see:
This validation subschema ensures that `secret.args` contains zero or one vault input
269
+
arguments. Defining a vault input argument is optional. Extensions that don't define the
270
+
vault input argument don't support retrieving secrets from a specific vault. Defining
271
+
more than one vault input argument is invalid.
272
+
properties:
273
+
args:
274
+
errorMessage: |-
275
+
The `secret` command defines the vault input argument more than once. If you don't define the vault input argument, DSC can't pass the vault to the extension for retrieving a secret from a specific vault. You can only define one vault input argument for the command.
276
+
277
+
You can define one argument in `secret.args` as a JSON object with the `vaultArg` property. For more information, see:
0 commit comments