Expose provisioning profile inputs in human-readable --list output - #284
Merged
Merged
Conversation
`avocado provision --profile tegraflash-usb` had no way to name which disk to provision except the generic `--env AVOCADO_PROVISION_USB_DEVICE=sda` passthrough, which works but isn't discoverable in --help and gives no indication the USB profile needs a device at all. Added a dedicated --usb-device flag that folds into AVOCADO_PROVISION_USB_DEVICE the same way --profile already folds into AVOCADO_PROVISION_PROFILE in build_env_vars. Named it usb-device rather than device: Deploy already has a --device/-d flag meaning a network host (user@host:port), and reusing that name for a local block-device name on a sibling subcommand would read as the same flag with different semantics. Depends on the tegraflash-usb profile itself (avocado-linux/meta-avocado#407, not yet merged) - the flag is inert until that profile exists on the other end. Signed-off-by: Javier Tia <javier@peridio.com>
lee-reinhardt
requested changes
Sep 22, 2026
The --usb-device flag added a generic CLI flag for an input only one NVIDIA provisioning profile consumes. --profile selects an extensible procedure declared by the target's manifest; --usb-device exposed one procedure's particular input as if it were a general concept, which overstates its applicability to every other target's provisioning profiles. Removed the flag and its wiring from both provision commands and build_env_vars. AVOCADO_PROVISION_USB_DEVICE reaches the same profile through the existing generic mechanism: --env AVOCADO_PROVISION_USB_DEVICE=sda, with metadata declared in the target's own provision.fields (a manifest-repo change, not this one). To close the discoverability gap the flag was meant to solve, extended avocado provision --list's human-readable branch to print each profile's resolved fields (type, required/optional, and label or description) alongside the --env invocation to supply them. The JSON branch already resolved this metadata for the desktop app; the human branch printed only the profile name and script. Signed-off-by: Javier Tia <javier@peridio.com>
Nit from review on avocado provision --list's human-readable branch: `label.or(description)` dropped the description whenever a label was also set, even though the two carry different information - BOARDCTL_TARGET's label is "boardctl target" while its description explains what leaving the field empty does, guidance the CLI was silently discarding. Print the label alongside the field name/type as before, and add the description on its own line underneath when present, before the --env hint. Handles label-only and description-only fields without dropping either. Signed-off-by: Javier Tia <javier@peridio.com>
jetm
changed the title
lee-reinhardt
approved these changes
Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
avocado provision --list's human-readable output showed a profile's name and script and nothing else. A profile's env-backed input fields (label, description, type, required/optional, and how to supply each with--env) were only visible in the JSON branch, so discovering what a profile actually needs meant reading the manifest by hand.Solution
Extended the human-readable branch of
--listto resolve and print each profile's fields the same way the JSON branch already does: field name, type, required/optional, the label and/or description when set, and an--env NAME=<value>hint for supplying it.An earlier version of this PR added a dedicated
--usb-deviceflag for thetegraflash-usbprofile specifically. That approach was dropped: the generic--env/provision.fieldsmechanism already covers it, and a per-profile flag doesn't generalize to any other profile that declares fields. This PR is now the discoverability fix alone - showing what--envvalues a profile accepts - not a new flag.Key changes
src/commands/profiles.rs:--list's human branch now resolves each profile's fields viaresolve_profile_fields(the same helper the JSON branch uses) and prints them under the profile lineReviewer notes
Field declaration for
tegraflash-usbitself (the manifest-sideprovision.fieldsentries) is a separate change in the target's own manifest, not part of this repo - avocado-linux/meta-avocado#407. This PR is the CLI-side display change only and has no dependency on that PR merging first.