-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a (hidden, for now) show
command for tooling use
#616
Conversation
d7eb333
to
c630250
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Command looks good but have some questions around implementation.
e98cda2
to
ed1df65
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
Windows
Standalone Binary
Container
|
@abpiskunov, could you confirm that the output here has all the information you need to unblock the VS work? |
we can work with that format - yes. |
@wbreza Please take a look again when you have a moment - would love to have this in the next release to make it easier for VS to consume. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few non-blocking additional comments. I think this is fine for now but we'll need to continue work on splitting out some expectations on our Project
vs ProjectConfig
so it is easier to move these type of framework or service target concerns back into their respective components.
8df1d8c
to
afbef06
Compare
This makes the set of values smaller and doesn't use the word "language" which can be sort of confusing when it's set to something like "dotnet". As part of this, we normalize the output so that `type` is always one of `dotnet`, `python` or `node` to make consumers lives easier.
Consumers like Visual Studio need to understand the project file that is assocated with a dotnet service, not just the path to the directory the service lives in. Initially, this logic was in it the project reader (which builds a ProjectConfig), but that felt like the wrong location for the logic. We can't add this logic to `ProjectConfig::GetProject` because that call fails when the infrastructure for an appliaction has not been provisioned, and we want `azd show` to work even in that case. Longer term we should look into something that allows `GetProject` to work evern when infrastructure is not created, and at that point move this logic there, but for now we have this as a specific implementation detail of the show command.
d14a549
to
7114dcd
Compare
/check-enforcer override |
This change adds a new hidden command,
show
, which must be run with--output json
to do anything. When run like this,azd show
collects information about the project and presents it in a way suitable for consumption by tooling.We include information about each service, including the language type and path to the project as well as the target resource in Azure that will be deployed to, if we can determine it (if you haven't yet run
azd provision
or there is some other transient error, this information will be missing from the resulting JSON).An example (before provisioning):
After:
@vijayrkn and @abpiskunov, I made some slight changes to the format we were discussing in #241 but this should contain all the information you need. Is this going to be suitable or do you prefer services to be an array instead of a map, with a name property? This felt slightly more
jq
-able, so I went with that, but not wed to the output format.