HSLdevcom / helmet-ui

Graphical user interface for Helmet 4 model system

Helmet UI

Helmet UI is a desktop user interface for Helmet 4 Model System. Read the documentation in Finnish to learn how to use Helmet UI and Helmet 4 Model System. If you wish to develop the UI, continue below.

Development requirements

This is an Electron application written in JavaScript (NodeJS API and Electron API available within app), HTML and CSS.

• Git client
• Node.js 16 LTS & NPM
• EMME 4.x.x (Windows-only)
• [optionally] helmet-model-system (otherwise downloaded and auto-installed by the UI)

On Mac and Linux, Wine and Mono are also required to make the app for Windows.

Setup

Due to tight integration with EMME, the application is mainly targeted for Windows but can be developed on Mac and Linux as well. However, the final testing should always happen on Windows with Emme.

$ git clone <this repository>
$ npm install

See the documentation for preparing the Windows environment for testing. EMME and EMME-Python versions can be set in versions.js, affecting the automatic resolving of Python binary.

Running and building

npm start command is used to start the application in development environment. Running npm run make will create an installer binary to be distributed to end-users.

See also: Electronforge.io

Version control

Git is used as the primary tool for version control and master branch is the main development line, aka. bleeding edge. All changes should be made in dedicated feature/bugfix branches, followed by a pull request and a peer-review. Then, after all checks have passed, the branch may be merged in master.

Continuous integration

The application is built automatically by GitHub Actions when changes are pushed in master branch or pull requests are opened.

Releases are deployed automatically when changes are pushed in the release branch, which should be updated with master only to make new releases.

Publishing releases

The Electron Forge's Github publisher is used to upload files and draft a new release, thus avoiding the need to upload and tag releases manually.

The resulting draft must be reviewed, edited and approved in Github to make it publically available to everyone. This allows testing the package and making final fixes to it before making it public.

1. Test and bring all the desired changes in the master branch.
2. Remove if there's word SNAPSHOT in version field of package.json, and update version as per semver practises.
3. Switch to release branch
4. Merge master to release and push to remote
   • $ git merge master
   • $ git push
5. Wait for GitHub Actions to build the application.
6. Go to releases page page and Edit the newly created draft.
   1. Ensure the release name corresponds to version number
   2. Write a brief description (new features, changes, fixes etc)
   3. Check/uncheck the pre-release checkbox as needed.
   4. Select release branch as the target for tagging
   5. Press Publish release when all is good.
7. Switch back to master branch and update the version number matching the release. This can be updated to indicate a snapshot before next release (e.g. 1.3.0-SNAPSHOT) while said release (1.3.0) is in development, if necessary.
   1. package.json#L4
   2. package-lock.json#L3 and #L9

⚠️ You cannot create drafts with an existing version number (i.e. release name). Thus, any intermediate drafts must be deleted before pushing final tweaks and fixes for the version about to be released.