Closed cakrit closed 1 year ago
I'd like to add some details here:
I'll adjust the MSI's filename and upgrade path, for that the installer would require to keep an internal version number to detect if the same is installed (Windows installer will halt the installation then). If the MSI has a newer version number then it will try to backup the configuration, remove the distro, install the newer and restore config.
@Ferroin plz check docker_image_to_wsl_tar.sh, it already gets the latest netdata from docker, so we can probably hook up its execution to our nightlies and change it to pull the stable as needed.
The installer should be called netdata.msi. It shouldn't have any versions appear on it, think of it as our kicstart. Users will always need to download the latest from our repo. @Ferroin decide if we'll create releases for it, or just leave it in the repo itself.
It needs to be releases, storing regularly changing binary files in git is not sustainable long-term for multiple reasons, and makes it difficult for normal users to fetch older versions of the installer.
Depending on the complexity of getting WiX working in GitHub Actions, I can probably have a basic workflow ready some time tomorrow, and from there it should be trivial to add a hook to the end of our Docker build workflow to trigger an update to the MSI.
I'll adjust the MSI's filename and upgrade path, for that the installer would require to keep an internal version number to detect if the same is installed (Windows installer will halt the installation then). If the MSI has a newer version number then it will try to backup the configuration, remove the distro, install the newer and restore config.
I think we’re fine just using the build date and time (ISO 8601, all non-numeric characters removed) for the version for this purpose. We can easily put info in the release description about which version of Netdata the installer includes.
This sounds great. Let's please ensure we have this working today at least, it doesn't need to be perfect, but functional.
Keep in mind that we'll delete all the produced nightly releases once we have finished everything, and switch to stable only, as you suggested @Ferroin
Associated PR: https://github.com/netdata/msi-installer/pull/16
Planning to merge that shortly, and then start debugging any issues with the GHA workflows, but I expect it to work as-is.
CI is in place. Release generation can be manually triggered by going to https://github.com/netdata/msi-installer/actions/workflows/build.yml and using the ‘Run Workflow’ dropdown with the default options that get autofilled there.
I’m holding off on adding automatic triggering of release generation from our main repo’s CI until we make the switch to using stable builds for this.
Great, thanks @Ferroin @dfpr what about your part?
After having the installer working I'll add the configuration restore/backup step.
Installation now leaves log at c:\netdata.log. Proper upgrade and configuration backup/restore pending.
We won't consider the updater a blocker for the official announcement, though it is of course very important to have the ability to get newer netdata versions without completely unistalling it.
Same for finishing the CI/CD for stable releases. We can keep it manual in the beginning and still announce it.
The MSI now reinstalls and does a backup/restore of /etc/netdata
, no need to restart.
Sorry I didn't check before, but it needs /var/lib/netdata
and /var/cache/netdata
as well.
Latest change does backup/restore those folders as well.
I will test this as soon as we get a new version with the change in wsl.conf reverted.
The installer worked fine when I ran it again over an existing installation.
We need to explain what we'll be doing and what our users will need to be doing, but for stable releases only, no nightlies for this.