Merge pull request #135 from tum-esm/main

v4.0.6

.github/workflows/test-on-push-to-main.yml → .github/workflows/test-on-main.yml

@@ -1,4 +1,4 @@
-name: 'test-on-push-to-main'
+name: 'test-on-main'
 on:
     push:
         branches:

.gitignore

@@ -1,51 +1,28 @@
-# python
+# development
 .venv
 *.pyc
 .pytest_cache
 __pycache__
 .coverage
 test-tmp/
-
-# config
-config/config.json
-config/config.tmp.json
-config/*.lock
-.env
-packages/cli/alias/pyra-cli.bat
-
-# logs
-*.log
-logs/.logs.lock
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-lerna-debug.log*
+.DS_Store
+.vscode/
+.idea
+hidden/
 
 # runtime data
 pids
+*.log
+.env
 *.pid
 *.seed
-*.pid.lock
-.DS_Store
+*.lock
+!yarn.lock
+!poetry.lock
 *.dat
 *.txt
 runtime-data/
-pyra-core-process-state.json
-logs/persistent-state.json
-logs/activity/*.json
-logs/**/*.jpg
-!logs/helios/.gitkeep
-logs/helios/*
-
-# pyra ui
-packages/electron-ui/node_modules/
-packages/electron-ui/.webpack/
-packages/electron-ui/out/
-packages/ui/node_modules/
-
-# development
-.vscode/
-.idea
-hidden
-website/.docusaurus
-website/node_modules
+config/**/*.json
+!config/**/*.default.json
+logs/**/*
+!logs/**/.gitkeep

README.md

@@ -1,33 +1,5 @@
 # PYRA
 
-**For installation, see https://github.com/tum-esm/pyra-setup-tool**
+**Documentation on: https://pyra-4-documentation.netlify.app**
 
-<br/>
-
-## Repository Management & CI
-
-**Branches:** `development-...`, `integration-x.y.z`, `main`, `release`, `prerelease`
-
-**Hierarchy:** `development-...` contains stuff in active development and will be merged into `integration-x.y.z`. `integration-x.y.z`: Is used during active integration on the stations and will be merged into `main`. `main` contains the latest running version that passed the integration and will be merged into `release` once enough changes have accumulated. Any branch can be released into `prerelease` to run the CI-Pipeline on demand. `prerelease` will not be merged into anything else and is just used for development purposes.
-
-**Continuous Integration:** The CI-Pipeline runs every time a commit/a series of commits is added to the `release` branch. The CI compiles and bundles the frontend code into an installable windows-application. Then it creates a new release draft and attaches the `.msi` file to the draft. We can then manually add the release description and submit the release.
-
-**Testing (not in an active CI):** We could add automated tests to the main- and integration branches. However, most things we could test make use of OPUS, Camtracker, Helios, or the enclosure, hence we can only do a subset of our tests in an isolated CI environment without the system present.
-
-**Issues:** Things we work on are managed via issues - which are bundled into milestones (each milestone represents a release). The issues should be closed once they are on the `main` branch via commit messages ("closes #87", "fixes #70", etc. see [this list of keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)). Issues that have been finished but are not on the `main` branch yet, can be labeled using the white label "implemented". This way, we can oversee incompleted issues, but don't forget to merge them.
-
-<br/>
-
-## Elements
-
-### FileLocks
-
-Since we have parallel processes interacting with state, config, and logs, we need to control the access to these resources to avoid race conditions. We use the python module [filelock](https://pypi.org/project/filelock/) for this. Before working with one of these resources, a process has to acquire a file lock for the respective `.state.lock`/`.config.lock`/`.logs.lock` file. When it cannot acquire a lock for 10 seconds, it throws a `TimeoutError`.
-
-When running into a deadlock, with timeout errors (never happened to us yet), the CLI command `pyra-cli remove-filelocks` removes all present lock files.
-
-### Version numbers
-
-Versions up to `4.0.4` are alpha and beta versions that should not be used regularly. PYRA can be generally used starting from version `4.0.5`.
-
-Inside the codebase, the version number is included 3 times: `pyproject.toml`, `packages/ui/package.json`, `packages/ui/src-tauri/tauri.conf.json`. The script `scripts/sync_version_numbers.py` takes the version number from the `.toml` file and pastes it into the other locations. This script can be run in a [git-hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks).
+[![Netlify Status](https://api.netlify.com/api/v1/badges/d573542a-adb3-446b-ad1a-1a97d07bacd8/deploy-status)](https://app.netlify.com/sites/pyra-4-documentation/deploys)

config/config.default.json

@@ -1,6 +1,6 @@
 {
     "general": {
-        "version": "4.0.5",
+        "version": "4.0.6",
         "seconds_per_core_interval": 30,
         "test_mode": false,
         "station_id": "...",
@@ -22,7 +22,7 @@
         "motor_offset_threshold": 10
     },
     "error_email": {
-        "sender_address": "pyra.technical.user@gmail.com",
+        "sender_address": "technical-user@domain.com",
         "sender_password": "...",
         "notify_recipients": true,
         "recipients": "your@mail.com"