Client Installer

[satyavel]

Over the next months/year we are going to be making and publishing many updates to 'Bicep_Release_win-x64' and other OS flavors. The PowerBI/Kusto client provides a really nice experience where everytime you run, it check for updates and automatically updates your files for you without any headaches. I wonder before public preview if we could leverage\build a similar solution which makes it extremely easy for customers to get the latest updates on their systems in a single click.

I know this would really reduce the barrier of entry for many customers and will get them going.

For Terraform they have one command 'brew upgrade terraform' which handles the upgrades. Wondering if we could do something similar.

[majastrz]

The brew command comes from HomeBrew package manager for MacOS X. The Kusto installation uses something called ClickOnce.

For every release, we will basically have to publish packages to all the package managers that we are interested in. We will also likely produce some non-package ship vehicles. Here are some options off the top of my head:

Windows

• ClickOnce app (not applicable)
• Setup exe/msi -- [Implemented]
• WinGet
• Chocolatey
  • Publishing packages

Linux

• .deb package
• .rpm package

Mac OS X

• HomeBrew -- [Implemented]

All OSs

• VSIX on VS Code Gallery
• Self-contained executables
• Az CLI extension
• dotnet install

[alex-frankel]

Need to figure out code signing with MS certs

[alex-frankel]

Scope for 0.3:

• package generation, signing, etc. should all be automated
• linux coverage
• "proper" homebrew support
• possibly choco/winget for windows

[alex-frankel]

One more scenario that came up in #1198:

It should be easy to be aware of and install updates to the CLI. For example, let's say I am using Bicep v0.3, and v0.3.1 is released. If I run any bicep command, I should be notified that an update is available:

bicep build main.bicep

Should show me an output like the following:

An update for the Bicep CLI is now available: v0.3.1

To install the latest version, follow the install instructions at aka.ms/installBicep

What would be nicer, but I'm not sure is technically feasible, is to provide an update command like bicep update. What's not clear to me is how does the CLI know which install path to use given the current OS. E.g. If I am on windows, should it use winget, choco, or setup.exe?

[anthony-c-martin]

What would be nicer, but I'm not sure is technically feasible, is to provide an update command like bicep update. What's not clear to me is how does the CLI know which install path to use given the current OS. E.g. If I am on windows, should it use winget, choco, or setup.exe?

In my experience I've seen updatable tools fall into two camps:

1. Installation and updates fully managed by the tool (not part of a package manger)
2. Installation and updates fully managed by the package manager

I don't see a huge problem with providing a version check, as long as it is checking the appropriate package manager feed, and not fetching that information from elsewhere - otherwise there's a potential to be out-of-sync.

Providing a bicep update command which knows how to interact with the appropriate feed (while probably technically possible, but complex) to me feels at-odds with being managed by a package manager; I would expect a user to either use the platform-native tools, or to follow instructions on how to do so. My vote would be to only provide this functionality if the CLI is not managed by a package manager (in which case, I'd definitely like this functionality).

[majastrz]

We may end up supporting multiple package managers on a single platform (for example choco and winget on Windows). Built-in update checks integrated with a package manager would require detection logic to figure out which one installed the currently executing version of the CLI as well.

[PartTimeLegend]

Any idea when we can expect this available via Chocolatey?

[alex-frankel]

We are going to re-evaluate the need for this once #858 is done. At that point, the need to compile bicep directly yourself should go way down. If we determine we still need this, we can probably get it done as part of 0.4 work.

[onionhammer]

dotnet install support seems like the ultimate in low-hanging fruit for this team that could easily.. easily get done. What is the reasoning for not just having this as an option?

[PartTimeLegend]

Now available via Chocolatey! Thank you!

[alex-frankel]

Thank @piraces :)

[piraces]

For the Chocolatey package, you can find the repository for which handles it in https://github.com/piraces/chocolatey-packages.
It automatically checks for updates every eight hours (5 */8 * * *), and push a new version if available (the pipeline: https://ci.appveyor.com/project/piraces/chocolatey-packages).

It's currently managed by the community, checksums are verified and the publication is reviewed by a moderator.

Nevertheless, I'm open to any change you find necessary / interesting. Talking to the Chocolatey community, they informed me about how to transfer the mantaintenance to you if you are interested (a Chocolatey account managed by you would be necessary).

So anything you want about this process I'm open to help out!

[piraces]

I have also seen that you were interested in publishing Bicep in Winget which its actually done by @DW-42 here...

Another widely used package manager for Windows users is Scoop, which I opened a PR to some days ago, which should autoupdate following the documentation.

I have done this to contribute and hoping this would help users ease the process to use Bicep 😄

Nevertheless, anything you may consider don't hesitate to contact me or reach me out!

[anthony-c-martin]

Closing as we've added support to various packaging systems. Please open new issues if a specific new scenario comes up.