/ build (push) Successful in 5m30s

Details

feat(embedded_ui): fully integrate UI into GoLang binary (#43 )

Reviewed-on: #43
Co-authored-by: Varakh <varakh@varakh.de>
Co-committed-by: Varakh <varakh@varakh.de>

2024-10-25 14:12:35 +00:00

3.5 KiB

Raw Blame History

upda-ui

Frontend for upda - Update Dashboard in React, TypeScript, Redux.

The main git repository is hosted at https://git.myservermanager.com/varakh/upda-ui. Other repositories are mirrors and pull requests, issues, and planning are managed there.

Contributions are very welcome!

Official documentation is hosted in a separate git repository.

Development & contribution

Contributions are very welcome!

Prerequisites

It's probably worth checking out a node environment manager like nvm manager.

Required node and npm versions are outlined in the package.json.

Setup instructions

Run npm install which should install all dependencies.

Start

Use the npm run start command to start the development setup. Backend should be running.

Configuration magic in docker

What about configuration? How does the pre-compiled set of html, js and css files know about the environment variables?

In contrast to manual build, the docker image allows dynamic override of configuration, but only those outlined in the .env file.

In production, all configuration values are dynamically generated inside the Docker image with a helper script called docker-env.sh:

During docker build a template .env file and the helper script are copied to the docker image
Before the container's nginx is started, the helper script
1. scans the .env file for known configuration variables and then
2. adds their values to conf/runtime-config.js which is sourced inside the application in the immutable window.runtime_config object

During development, this runtime-config.js file is still loaded, but empty and thus the getConfiguration() ignores it and prefers values from the sourced .env.development.

This means that new environment variables need to be added to all .env* files!

Release

Releases are handled by the SCM platform and pipeline. Creating a new git tag, creates a new release in the SCM platform, uploads produced artifacts to that release and publishes docker images automatically. Before doing so, please ensure that the commit on master has the correct version settings and has been built successfully:

Adapt package.json and change version to the correct version number
Invoke npm install once which properly sets the version inside the lock file
Adapt language files, e.g., en.json and change version to the correct version number
Adapt CHANGELOG.md to reflect changes and ensure a date is properly set in the header, also add a reference link in footer
Adapt env: VERSION_* in .forgejo/workflows/release.yaml

After the release has been created, ensure to change the following settings for the next development cycle:

Adapt package.json and change version to the next version number (semantic versioning applied, so patch should bump patch level version and prepare branch for develop should bump minor or major version)
Invoke npm install for each of those branches which properly sets the version inside the lock file
Adapt language files, e.g., en.json and change version to the next version number (semantic versioning applied, so patch should bump patch level version and prepare branch for develop should bump minor or major version)
Adapt CHANGELOG.md and add an UNRELEASED section
Adapt env: VERSION_* in .forgejo/workflows/release.yaml to next version number

3.5 KiB Raw Blame History