chore: Create release artifacts

[benscobie]

This PR adds artifact creation to the release workflow, providing downloadable archives alongside the GitHub release, which can be extracted, configured and ran without having to mess around with building it yourself. This also provides an avenue for non-Docker installation methods such as community-scripts/ProxmoxVE#97 . I've included an install script, basic run scripts and config files, which serve as a base for other implementations that want to use the release archives.

A basic install guide would look like:

1. Download the appropriate archive from the GitHub release page
2. Extract the archive to the final installation directory
3. User creates a directory to hold Maintainerr data
4. Run install.ps1 / install.sh
5. Update ./server/.env and ./ui/.env
6. Use start_ui.ps1 / start_ui.sh and start_server.ps1 / start_server.sh to start the UI and server.

An upgrade would currently involve:

1. Make a copy of server/.env and ui/.env
2. Delete the installation directory (the data dir should be moved out, or ideally not be in here at all)
3. Follow the install guide from step 2. Use your backed up .env files instead of updating the existing ones.

Workflow

I have added a new step to the release workflow that builds the project in the same way as we do in Docker. This will output an archive for each platform (currently Linux amd64, Linux arm64 and Windows x64), which will then be attached to the release created in GitHub by semantic-release.

I have updated how semantic-release is called as well. First we do a dry-run to get the version number, which also validates that the actual release will go okay (most of the time). The Docker & release archives steps will then fire off in parallel, and once those are complete, semantic-release is is called again to perform the GitHub release.

Finally, I managed to reduce the Docker image size from 650MB to around 350MB by removing node dev dependencies after the build. This saving also applies to the new release artifacts.

Configuration changes

In order to make configuration easier for users, I have updated the UI & server to make use of .env files. There are a few different variations in-use here:

• .env - This can be seen as our 'default' configuration options. The %GIT_SHA% token is replaced at build time. The .env files below will override configuration defined in here.
• .env.distribution - This file is included in the release archive and is the file that the user modifies to change configuration.
• .env.docker - This file contains the hard-coded values that were in the Dockerfile. I have removed them from there because of this issue with Portainer. There is no change for Docker users here. They can continue to specify configuration via environment variables, which have a higher precedence than .env files.
• .env.local - This file is not included in any release artifacts. It is used to specify configuration for the local development environment.

As part of the build process, .env.distribution / .env.docker, is copied to .env. The .env file is copied to .env.production.

The final output is:
/ui/.env - this was .env.distribution or .env.docker
/ui/.env.production - this was .env
/server/.env - this was .env.distribution or .env.docker
/server/.env.production - this was .env

Code changes

• I have updated the about page to get the new DATA_DIR configuration value
• Removed any fallback values when referencing undefined process.env props. These defaults are now centrally specified in the .env files.

Testing

• Windows x64 - Tested on Windows 11
• Linux x64 - Tested on Debian 11
• Linux arm64 - Tested on an emulated arm64 VM

Future

I would like to improve the install, upgrade and run/stop processes in a future release. A few ideas I've had:

• Provide docs/scripts for integration with systemd, Windows Services, etc.
• Create an install script that can be curl'd which grabs the latest release and installs it. Inspired by Sonarr here.
• Create a Windows installer which will handle installing & upgrading, as well creating a Windows Service to run the apps.
• I would love to have just a single process to run. I originally wanted to ship with pm2 but I couldn't get it to work. We might be able to create a custom server that inits both the UI & server.
• Provide docs for platforms like Synology

[jorenn92]

@benscobie, I (finally) had some time to take a look at this. It's a big change, but it looks solid!
I'd like to take the time to try building locally as well though, before approving this.

[benscobie]

I'd like to take the time to try building locally as well though, before approving this.

Of course!

The packaging is all located within these scripts to make it easier to test locally, you just need to pass a Git SHA as an arg (can be anything really though):
./distribution/prepare_artifact_linux.sh gitSHA
./distribution/prepare_artifact_win.ps1 gitSHA

What I was doing locally was:

• yarn build
• yarn workspaces focus --all --production
• ./distribution/prepare_artifact_win.ps1 c74416fa702d6268fde3a77ed9a5df1306d513a1
• Take the output from the _output folder and put it somewhere like C:\Maintainerr\
• Configure the .env files
• Run install.ps1/sh
• Run start_server.ps1/sh & start_ui.ps1/sh

You can also execute the release workflow to generate the artifacts, just target this branch (though it is in my fork so likely won't be listed..). Just enable Dry run and uncheck Build and push Docker images. They'll be available alongside the action, e.g. https://github.com/benscobie/Maintainerr/actions/runs/14433809972

[jorenn92]

I'd like to take the time to try building locally as well though, before approving this.

Of course!

The packaging is all located within these scripts to make it easier to test locally, you just need to pass a Git SHA as an arg (can be anything really though): ./distribution/prepare_artifact_linux.sh gitSHA ./distribution/prepare_artifact_win.ps1 gitSHA

What I was doing locally was:

* `yarn build`

* `yarn workspaces focus --all --production`

* `./distribution/prepare_artifact_win.ps1 c74416fa702d6268fde3a77ed9a5df1306d513a1`

* Take the output from the `_output` folder and put it somewhere like `C:\Maintainerr\`

* Configure the `.env` files

* Run install.ps1/sh

* Run start_server.ps1/sh & start_ui.ps1/sh

You can also execute the release workflow to generate the artifacts, just target this branch (though it is in my fork so likely won't be listed..). Just enable Dry run and uncheck Build and push Docker images. They'll be available alongside the action, e.g. https://github.com/benscobie/Maintainerr/actions/runs/14433809972

Very nice, thank you for the clarification!