Set up a CI workflow to automatically publish a release on tag
Build a lit.exe (Windows x64 binary) and append it to the release
In order to build it, the pinned Luvi version is taken from package.lua (this part is ugly... suggestions welcome)
After the executable is built, a basic smoke test suite is run to verify the build (currently placeholder/POC implementation. One step at a time :P)
Why is it needed?
Technically it isn't needed, but making lit accessible without having to deal with PowerShell will improve the accessibility for new/inexperienced, or even just lazy users. This is not the best solution I can imagine to improve the new user experience, but it is a step in the right direction nonetheless.
This would also allow linking the release directly on the website, where currently a placeholder TODO text is located. I probably don't need to tell you again how bad of a first impression that is, so let's move one step closer to changing it :)
Why no OS X/Unix/etc builds?
I don't think users of these systems are nearly as allergic to CLIs as the average Windows user, and setting things up with the existing makefile is probably easy enough for now. Creating a proper OS X installer seems like it could be valuable, but I have no such system available so it'll have to wait until a later point in time.
It's also probably better to create one installer for all components, which is something I've been looking into as well (work in progress) but otherwise unrelated to this PR.
Why make Luvi from scratch instead of downloading a release?
Originally, I had intended to always use the latest version (and make the executable after git clone). If the version is to be pinned, as it currently is, then one could just as easily download the executable and use it directly, but this wouldn't be as flexible so I can't re-use the workflow for modified versions or other related tasks.
Not sure on this one TBH, if you like I can easily change it.
What does it do?
lit.exe(Windows x64 binary) and append it to the releasepackage.lua(this part is ugly... suggestions welcome)Why is it needed?
Technically it isn't needed, but making
litaccessible without having to deal with PowerShell will improve the accessibility for new/inexperienced, or even just lazy users. This is not the best solution I can imagine to improve the new user experience, but it is a step in the right direction nonetheless.This would also allow linking the release directly on the website, where currently a placeholder TODO text is located. I probably don't need to tell you again how bad of a first impression that is, so let's move one step closer to changing it :)
Why no OS X/Unix/etc builds?
I don't think users of these systems are nearly as allergic to CLIs as the average Windows user, and setting things up with the existing
makefileis probably easy enough for now. Creating a proper OS X installer seems like it could be valuable, but I have no such system available so it'll have to wait until a later point in time.It's also probably better to create one installer for all components, which is something I've been looking into as well (work in progress) but otherwise unrelated to this PR.
Why make Luvi from scratch instead of downloading a release?
Originally, I had intended to always use the latest version (and make the executable after
git clone). If the version is to be pinned, as it currently is, then one could just as easily download the executable and use it directly, but this wouldn't be as flexible so I can't re-use the workflow for modified versions or other related tasks.Not sure on this one TBH, if you like I can easily change it.
Demo
This is a full run of the current iteration of the workflow: https://github.com/LuvitPlayground/lit/runs/3752015499
The release is currently very barebones, but it looks like this: https://github.com/LuvitPlayground/lit/releases/tag/windows-build-demo-release
Note: In order to use this workflow, a GitHub Token must be added as a repository secret (to actually publish the release).