Establish cron-based nightly releases

[matklad]

We have a release workflow which is kicked "manually" when I push to the release branch. We should supplement it with a nightly workflow that runs at midnight. There are two goals here:

• make it easier for users to follow the bleeding edge,
• make sure that release process "just works" and doesn't require manual intervention; running releases once per week is not frequent enough to address regressions.

Some notes:

• we should share the same workflow file for both nightly & weekly releases
• VS Code extensions don't have nightly/stable channels, so we should just publish a separate rust-analyzer-nightly extension
• we ideally, we should have just one tag for nightly releases
• however create-release action can't delete-release, d'oh. There was a fork of it that could though, we should use it (pinning the action with SHA hash or forking it, because actions are not frozen by default).

[Veetaha]

I know cpp-tools extension has a nightly release channel, we could learn from them...

[Veetaha]

They download .vsix according to the updates channel and replace it with the extension itself I guess
Also, note that they have platform-specific .vsix releases (i.e. binaries are bundled inside of .vsix)

[Veetaha]

@matklad should we use only one github release for nightly build? I.e. we delete the release and create it once again but from current master branch? Also do we put a git tag nightly on commits?

[matklad]

I think it makes sense to have one release, and one moving tag

[matklad]

Yeah, as much as I hate it, I guess we'll need to implement the "download vsix and update yourself" trick: you can't publish plugins with proposedApi: true, but a major benefit of nightlies is using propsed apis....

[Veetaha]

Okay, this is the VSCode's fault, the workaround is what we are left with

[matklad]

Status: nightly releases work, we now need support in the front-end to actually use those nightlies without installinng them manually.

[Veetaha]

Sure thing, I'd like to drive this on frontend!

[Veetaha]

Investigation

Having looked at vscode-cpptools releases I see the following:

• cpptools publishes their insiders outside of any fixed schedule
• cpptools relies on semver version when selecting the insiders build
• cpptools suggests the user to use insiders if she hasn't yet and polls for updates each hour
• cpptools self-overrides the extension via downloading .vsix and installing it

I would also want to elaborate on some invariants I suppose we need to maintain (according to my experience at rust-analyzer)

• The extension never issues requests via the network without notifying the user (cpptools trespasses this)
• rust-analyzer uses date-based version naming

Proposal

Selecting the update channel and/or binary path

I suggest two options

• We contribute "rust-analyzer.updateChannel": "stable" | "nightly" config to settings.json
  This way we maintain backward-compat and provide good UX (i.e. the setting is declared as an enum so the user is aware of the two possible values).
  However, this means that updateChannel and serverPath are mutually exclusive (that @matklad proposed to avoid Feature: "Download latest language server" command for VS Code #3073 (comment)) or otherwise just consider explicit serverPath to take precedence.
• We reuse "rust-analyzer.serverPath" and make it three-state, namely
  • stable (default) - we ensure the stable release extension and prebuilt binary version installation
  • nightly - we ensure the nightly extension and prebuilt binary version installation
  • /explicit/path - we use the binary supplied by the user disregarding anything else
    However, I can't think of the best name for this config property, since calling it just rust-analyzer.server seems odd since this determines not only the version of the server but the frontend altogether. This will also define stable and nightly as special treated values, that the user cannot use as a path to the binary (but this is quite a minor point).

Pop-up message

• We contribute "rust-analyzer.alwaysDownloadServer": true | false config to settings.json that determines whether we show the Download now pop-up dialog each time before downloading the binary/vsix and use its value as an answer.
• The pop-up now additionally proposes Download now (nightly). We persist this choice to the global settings.json.
• We could add Download now (nightly) (always), Download now (always) and No (always) buttons to the pop-up message and modify the global settings.json but it complicates the UI with 6 buttons instead of 3 (I wish we could add a checkbox here, but there is no API for that...)

Frontend versioning

• To detect the nightlyness of the frontend I suggest two options:
  • We check for "useProposedApi": true in package.json (not very evident and stable)
  • We add -nightly suffix to the version in package.json. I also suppose we have to ensure that the version of nightly is greater than the one available in the marketplace. I guess we can change dev to nightly suffix in package.json and ship it as is for nightly releases.
    https://github.com/rust-analyzer/rust-analyzer/blob/aff82cf7ac172f213cb5dcca637cb2c5332294c1/editors/code/package.json#L8-L9

Implementation details

• We save not only the release name, but the published_at date to the globalStorage
• When we detect that the frontend is nightly we need to check if there is a new nightly release available. The easiest solution is to fetch release info from github.com and compare its date with the one saved to globalStorage, however, this might mean using the network without user's permission or spamming info messages about checking for updates each time the extension is started which also adds some overhead (maybe another dontAskMeAgain option).
  To avoid requests we may heuristically propose to update the currently nightly if the current nightly version was published more than 25 hours ago (but this might also involve quite a lot of false-positives when the user changes its os time and whatever).
• Another option would be to ship the nightly binaries in .vsix itself, but that would mean that the nightly frontend implementation would deviate from stable. And we would need to duplicate the binaries in .vsix packages and outside of them in the nightly release in order to let users of non-vscode editors download them apart from .vsix .

Downgrading from nightly to stable

Once the user changed from nightly to stable we propose her to uninstall the extension and install it again, maybe even use one of

• workbench.extensions.action.reinstall
• workbench.extensions.action.install.specificVersion
  (I am not sure they are public, will need to investigate, but that's not very important)

@matklad do you have some thoughts on the preferred options above or maybe other approaches in mind?

[Veetaha]

Some more thoughts:
Download now (nightly) button would be deceiving to some degree, because it won't install the nightly server binary right away, it will install the nightly extension that in turn will propose to install the binary.

[matklad]

"rust-analyzer.updateChannel": "stable" | "nightly"

I like this

We add -nightly suffix to the version in package.json

I like this as well. Since we are not publishing nightly, we can actually do this now

To avoid requests we may heuristically propose to update the currently nightly if the current nightly version was published more than 25 hours ago

I like this: I wondn't worry about false positves until users complain :D

The pop-up now additionally proposes Download now (nightly).

Why do we need it? It think just having a config in settings.json for channel should be enough?

[Veetaha]

Agree on not having the Download now (nightly). I was just trying to mimic vscode-cpptools behaviour. They propose to switch to nightlies and if the user rejects they never ask again. I guess this is unnecessary as per you.