Release nightly builds

[the-mikedavis]

This was simpler than I was expecting. Most of the work is being done by this action: https://github.com/softprops/action-gh-release which can create the tag and release if they are not already made as well as upload artifacts and control whether a release is a pre-release or regular.

Example output: https://github.com/the-mikedavis/helix/releases/tag/2022-04-21-nightly (the AppImage version has been fixed)

closes #358

[the-mikedavis]

0300UTC seems like a reasonable default I pulled from what EventStore does (see here). I'm not attached to it though. We might also want to try something less than nightly at first like weekly / bi-weekly / (the other meaning of) bi-weekly / every other day

[David-Else]

Cheers! But is it possible to compile as musl for glib 2.28? https://github.com/the-mikedavis/helix/releases/download/2022-04-21-nightly/helix-dev-x86_64.AppImage

/tmp/.mount_helix-hFKChY/usr/bin/hx: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_helix-hFKChY/usr/bin/hx)

#1932

[the-mikedavis]

Ah right musl C. I'll take a look at that in a follow-up PR. There might be some difficulties getting everything to compile correctly (the cross compiling toolchain can be fussy some times with the tree-sitter C) so I'd like it to be its own focus

[dead10ck]

This looks good to me! Thanks

[pickfire]

Also, with these changes I think we need to note it in the changelog so that maintainers can put up a nightly version as well.

[the-mikedavis]

Oh, like maintainers having nightly builds in their forks? That could be fun to build testing releases of PRs in advance

[pickfire]

Looks good to me, just have to put it in changelog for maintainers.

[rsHalford]

With the addition of a nightly branch, would it be best if a nixpkgs overlay was maintained under the helix-project or through nix-community, like with the neovim-nightly-overlay?

[the-mikedavis]

An overlay in nix-community would be great. We have cachix set up on the flake on master but we use up the 5GB pretty quickly - being in the nix-community cache (1TB) would probably be much faster for people who want to follow nightly.

[the-mikedavis]

Thinking about this more, I think we're better off for the time-being encouraging building from source instead of the nightly. IMO it's not so much easier to use the pre-build releases than to just build from source. Releases are easier if you don't want to install a Rust toolchain however.

Don't worry, you can still have your cake and eat it too: you can fork the Helix repo, go to the Actions tab and hit enable. If you want to build yourself nightly releases, you can cherry-pick these commits onto your master. For the most part though it should be sufficient to just push a new tag to your fork in the format of '[0-9]+.[0-9]+(.[0-9]+)?' whenever you want to make yourself a release.

[kamalmarhubi]

@the-mikedavis would you reconsider merging this? Low-friction nightly builds mean easier uptake and testing by the community. This means higher chances of finding bugs, and more feedback on new features.

For specific package ecosystems:

• for the the arch community's AUR, there's a convention of -nightly-bin for packages that have nightlies upstream (see search results)
• for homebrew on macos, there are numerous nightly versions in Homebrew/homebrew-cask-versions

[the-mikedavis]

I don't have any plans to reconsider but I'll keep this in the back of my mind.

Those ecosystems allow you to build from git/head: https://aur.archlinux.org/packages/helix-git and https://github.com/helix-editor/homebrew-helix/blob/5d96bef0d64d21af9092a181a25c6cd5fe452e14/Formula/helix.rb#L9-L12.

[filipdutescu]

Just wanted to mention this might not be such a bad idea from an environmental point of view either, as time and energy could be saved by having a nightly build (which is created only if merged were made in the last day).