Fix azd issue #393 - #4567
Merged
Merged
Conversation
v-weiyding
requested review from
ellismg,
hemarina,
vhvb1989,
wbreza and
weikanglim
as code owners
November 19, 2024 10:00
wbreza
reviewed
Nov 21, 2024
vhvb1989
approved these changes
Dec 5, 2024
vhvb1989
left a comment
vhvb1989
left a comment
Member
There was a problem hiding this comment.
small fix requested. otherwise LGTM
vhvb1989
approved these changes
Dec 6, 2024
ellismg
added a commit
to ellismg/azure-dev
that referenced
this pull request
Dec 9, 2024
When running `azd restore` for a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications: 1. If you didn't have the tool that was going to be invoked during `restore` installed (i.e. you didn't have `npm` for a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool. 2. As of Azure#4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so `azd restore` now fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI). To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the `ProjectManager` now has a `EnsureRestoreTools` method. As part of this, I also changed the `ProjectManager` such that `Initialize` no longer calls `EnsureAllTools` (which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were calling `EnsureAllTools` themselves or another `EnsureXXXTools` variant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call to `EnsureAllTools` from `Initialize`. Fixes Azure#4612
ellismg
added a commit
to ellismg/azure-dev
that referenced
this pull request
Dec 9, 2024
When running `azd restore` for a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications: 1. If you didn't have the tool that was going to be invoked during `restore` installed (i.e. you didn't have `npm` for a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool. 2. As of Azure#4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so `azd restore` now fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI). To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the `ProjectManager` now has a `EnsureRestoreTools` method. As part of this, I also changed the `ProjectManager` such that `Initialize` no longer calls `EnsureAllTools` (which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were calling `EnsureAllTools` themselves or another `EnsureXXXTools` variant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call to `EnsureAllTools` from `Initialize`. Fixes Azure#4612
ellismg
added a commit
to ellismg/azure-dev
that referenced
this pull request
Dec 11, 2024
When running `azd restore` for a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications: 1. If you didn't have the tool that was going to be invoked during `restore` installed (i.e. you didn't have `npm` for a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool. 2. As of Azure#4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so `azd restore` now fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI). To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the `ProjectManager` now has a `EnsureRestoreTools` method. As part of this, I also changed the `ProjectManager` such that `Initialize` no longer calls `EnsureAllTools` (which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were calling `EnsureAllTools` themselves or another `EnsureXXXTools` variant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call to `EnsureAllTools` from `Initialize`. Fixes Azure#4612
ellismg
added a commit
that referenced
this pull request
Dec 11, 2024
When running `azd restore` for a Docker based project, we were requiring that the docker tool itself was installed instead of whatever tool would be used by the actual source project. This has two implications: 1. If you didn't have the tool that was going to be invoked during `restore` installed (i.e. you didn't have `npm` for a node based project), we wouldn't detect the fact upfront and provide a nice error, we'd fail later when we tried to invoke the tool. 2. As of #4567, we now require that the docker daemon be running to consider docker "installed" (which is reasonable for cases where we are going to invoke docker commands) and so `azd restore` now fails if you have a docker based project but are not running the docker deamon (as is the case in the macOS environment in CI). To fix both of these issues, I decided to accept the fact that ensuring the tools needed to do a restore is different from the other cases, and so the `ProjectManager` now has a `EnsureRestoreTools` method. As part of this, I also changed the `ProjectManager` such that `Initialize` no longer calls `EnsureAllTools` (which is logically did before, it had just inlined the logic) and audited all the callers to ensure that they were calling `EnsureAllTools` themselves or another `EnsureXXXTools` variant (doing so also made me realize a lot of the care we had put into some of the commands controling what sets of tools they checked for via these special Ensure methods was being undone by the implict call to `EnsureAllTools` from `Initialize`. Fixes #4612
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
3 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.
Fix #393.
Add code to the
CheckInstalledfunction in thedocker.gofile to check if Docker is running.The latest error information is shown below:
@rajeshkamal5050 for notification.