azure-dev
azure-dev copied to clipboard
Azure
[Issue] Surface `docker build` output as part of `azd deploy` output
Right now, during azd deploy no information is shown around building a docker image. In the template I'm working on, the pip install takes a good while (not an azd problem :D) so this feels like a really long time without any progress (like ~5 mins):
I think it'd be really helpful to be able to see some of the steps happening under the hood. That way, the user is able to see exactly what step it's working on. We could consider surfacing the information in a "window" (similar to what pip install looks like below) to make it clear that this is a subprocess as part of azd deploy.
Adding @Austinauth.
currently, we don't have multi-line temporal log support for outputs. We only have single-line temporal log support.
@vhvb1989 Can you explain a little further? I'm not sure what that means.
@Austinauth Right now, we support single line status/progress (e.g. azd provision; each operation gets it's own line).
As part of azd deploy, we run docker build to build the container image before sending it off to ACR and then using it in the deployment. However, we don't actually show the Docker output as part of the azd deploy command. Instead, the user just sees image 1.
Image 2 is what the user sees if they run docker build outside of azd. This ask is to show users that progress and surface it in azd deploy. Coincidentally, the grey bit in the docker build image is similar to the behaviour I'm talking about. I can also show you when we meet next!
@savannahostrowski is the image in your post above about the average length of the typical Docker output? Could it be substantially longer?
It's a fixed-height, dynamic window. The output scrolls up as the build progresses.
After speaking with @wbreza here is the initial proposal for surfacing Docker output (or any output) in a sub-step. Consider these mock-ups as mid-fidelity and open to feedback. Wallace will be researching the feasibility of the output viewport illustrated in the screens below.
1) Output displayed during a sub-step as it completes
Docker output is displayed in a fixed-height, dynamic-width viewport beneath sub-steps where surfacing Docker output is critical. Viewport should be capped at roughly 12-14 lines (we can tweak as needed).
Content within the output viewport should maintain the style of the service it originates from (unless its easier for us to apply our own styles).
This pattern should scale to work for other types of output.
Nice to have:
- Ability to scroll up and down to view lines of text out of the view port.
- Ability to scroll up and down using keyboard inputs (↑ and ↓)
2a) Completion of a sub-step that surfaced Docker output
Upon successful completion of the sub-step Docker output should disappear, only persisting if the user ran the command with the -verbose flag. If this ends up feeling awkward or confusing in realtime we can adjust.
2b) Failure of a sub-step that surfaced Docker output
On error/failure the sub-step follows the traditional sub-step failure pattern UX, however the Docker output persists so that the user can better troubleshoot the cause of the problem.
Feedback needed:
- What is the appropriate Error hint text when a sub-step fails as part of an
azd deploy? Try again? - What is the appropriate Error hint text when a sub-step fails as part of an
azd up? The same thing we have for when the provisioning step fails?
@rajeshkamal5050 @Austinauth Let's chat about this in the biweekly demo on 2/21.
@vhvb1989 please take a look at the above proposed mockups. Remember you said it will be complex to get this done. Keeping it for the April fit-n-finish iteration and can be re-accessed based on the scope of work.
We can remove the ability to scroll up and down through the output if needed. From what I understand this would complicate things quite a bit.
I'm also okay with a lack of ability to scroll the output - that behaviour is what docker output looks like today.