search

Azure / azure-dev

A developer CLI that reduces the time it takes for you to get started on Azure. The Azure Developer CLI (azd) provides a set of developer-friendly commands that map to key stages in your workflow - code, build, deploy, monitor, repeat.
https://aka.ms/azd
MIT License
377 stars 173 forks source link

Initial Windows Installer project #797

Closed heaths closed 1 year ago

heaths commented 1 year ago

@jongio @danieljurek here's an initial installer projects, but I need to create a custom dialog set to not only allow the user to set whether to use a per-user (default) or per-machine - or should we, since it could be done for advanced scenarios via command line for admins setting up CI agents - and minimal install dialogs, like optionally setting the install dir. Again, though, we could elide that and let them do it via command line if they really need to. If we want to nix both dialogs, we may as well not even have custom UI and just let Windows Installer use the default basic dialog. It's concise.

jongio commented 1 year ago

What's a good way to test this?

heaths commented 1 year ago

Install 3.x of https://wixtoolset.org (it's installed by default on build agents for both AzDO and GH Actions), build the binary with GOOS=windows, and build the .wixproj. Alternatively, I could attach an MSI I built, but this is draft because I figured we have decisions to make about the UI sequence, if any. Last I heard from @danieljurek we didn't want to show a license dialog so I already removed that, but do we want to let them specify a location via UI (we could allow that only on command line, or not at all).

If we define UI, that's what users will see by default i.e., in the double-click scenario. What, if any, we want to allow to be settable such as install location (like I did for the GitHub CLI) or whether it's installed per-user (non-elevated; same location as now) or per-machine (elevated; accessible by any user process - good for CI agents) could be done via UI and command line, or only the command line for advanced scenarios such as CI agent provisioning.

heaths commented 1 year ago

Also, I hadn't hooked this up to the build yet but will. The question is whether we want the current install scripts to be removed yet, or wait until we finalize on plans for the MSI. At that point, I can start hooking up the publishing process for winget, chocolatey, and scoop.

danieljurek commented 1 year ago

We'll keep the installer scripts in the near term. We want a single, cross-platform approach to installing and the PowerShell script gives us that. It might make sense to use the PowerShell script to download and msiexec the MSI on Windows.

As for license, etc. I may have spoken incorrectly. I was trying to say that we want the install to be frictionless... though that may just require adding a /quiet switch to the install command line. If folks are used to clicking through some dialogs when, for example, installing packages via WinGet, then we should probably keep to those expectations as well as any legal/release requirements.

We'll probably also need to onboard to signing MSIs in our signing stage.

As for the release process, I think we should make these idempotent and possibly in separate jobs so, for example, a transient network error that breaks an update to Choco doesn't hold up releases to, for example, scoop and winget.

heaths commented 1 year ago

Here's what I need answers to:

  1. Do we need to show a license dialog by default? All UI can be silenced in UI and defaults mean acceptance.
  2. Do we want to let users pick their install path? Default would be what it is now.
  3. Do we want to let users decide to install per-user or per-machine? Default I recommend is per-user, which is what it is now.
ellismg commented 1 year ago

I wonder what we should do for our up-to-date check given this change. Today, on windows, when the CLI is out of date we print a message with the shell command invocation you can use to upgrade to the latest version. Would we continue to do this? If not, how do we decide if we want to print just a "there's an update available" message or a "there's an update available and here's the powershell command to go upgrade"? Separate builds? Have the MSI version lay down some file that the CLI probes for so it knows it came from an MSI?

heaths commented 1 year ago

Chocolatey, Scoop, and Winget all have their own ways to check for updates. You can still do an online update check and ask people to update, but since it's MSI you could also do what the Azure CLI does: download it (don't invoke the URL; I worked with them to fix that problem which gets blocked on some domains like ours) and install it. It's not hard to just shellex msiexec against a downloaded MSI. Winget, at least, will still detect the proper version. I think scoop will too, IIRC.

heaths commented 1 year ago

Where do we stand with this? I recommend using an MSI which you can install on Windows via the script if you like, but then it's also accessible via chocolatey, scoop, winget, and others that may have trouble with the script which downloads separately. Many of these deployment mechanisms are used to get bits on the box for possible offline use, like CIs that need to be provisioned online and build offline. A separate MSI will give you more flexibility.

/cc @jongio

danieljurek commented 1 year ago

@ellismg, @heaths -- The install script would need to change to support MSI. I think this is a reasonable approach. We'll end up keeping similar logic for linux/mac installs but adding a different code path to download an MSI file and run msiexec on it will be more straightforward than what we have today.

heaths commented 1 year ago

I'll finish this up and at least get the MSI publishing to releases. From there I can submit PRs to pull the latest from your scripts and start on workflows to publish to chocolatey (will need to wrap in a nupkg, but just to point at the MSI should be fine), scoop, and winget. Should I wait for a license, though, per our discussion?

danieljurek commented 1 year ago

@heaths, Yes. Let's go forward.

At this point we've discussed:

Still need to get closure on these topics:

danieljurek commented 1 year ago

@heaths ... One area I need to track down is how we'll do signing for the MSI. For example, do we need a two-phase signing process of signing the executable and then building an MSI and then signing the MSI?

rajeshkamal5050 commented 1 year ago

@savannahostrowski for non-trusted template warning notice. Is it during installation or per template execution we bring it?

savannahostrowski commented 1 year ago

@rajeshkamal5050 I need to get some guidance/insight from CELA before making this decision in product. Will have more details early next week.

heaths commented 1 year ago

@danieljurek yes the file will need to be signed, then the MSI.

savannahostrowski commented 1 year ago

@rajeshkamal5050 I need to get some guidance/insight from CELA before making this decision in product. Will have more details early next week.

Following up here, notices for template trust do not need to be surfaced with the MSI installation.

azure-sdk commented 1 year ago

Azure Dev CLI Install Instructions

Install scripts

MacOS/Linux

May elevate using sudo on some platforms and configurations

bash:

curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797 --version '' --verbose

pwsh:

Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797' -Version '' -Verbose

Windows

powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/797' -Version '' -Verbose;"

Standalone Binary

Container

docker run -it azdevcliextacr.azurecr.io/azure-dev:pr-797