Merge branch 'development'

Author: karel26

.github/workflows/pages.yml

@@ -24,39 +24,30 @@ on:
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
   contents: write
-  pull-requests: write
   pages: write
   id-token: write
 
 # Allow one concurrent deployment
 concurrency:
-  group: "pages"
-  cancel-in-progress: true
+  group: "pages-deployment-${{ github.ref }}"
+  cancel-in-progress: false
 
 jobs:
   # Sync job
   sync:
     runs-on: ubuntu-latest
-    if: |
-      github.event_name == 'push' && 
-      !contains(github.event.head_commit.message, 'Update documentation') &&
-      !contains(github.event.head_commit.message, 'Merge pull request')
+    if: github.event_name == 'push'
+    permissions:
+      contents: write
     steps:
       - name: Checkout
         uses: actions/checkout@v4
         with:
+          token: ${{ secrets.GITHUB_TOKEN }}
           ref: development
 
       - name: Sync and commit documentation
         run: |
-          # Ensure we have the latest development branch
-          git fetch origin development
-
-          # Create a new branch with timestamp to avoid conflicts
-          BRANCH_NAME="docs-update-$(date +%Y%m%d-%H%M%S)"
-          echo "BRANCH_NAME=$BRANCH_NAME" >> $GITHUB_ENV
-          git checkout -b $BRANCH_NAME
-          
           # Create temporary backup directory
           mkdir -p temp_backup
 
@@ -147,57 +138,22 @@ jobs:
               done
             fi
           done
-
-          # Configure git
-          git config --local user.email "github-actions[bot]@users.noreply.github.com"
-          git config --local user.name "github-actions[bot]"
-          
-          # Add and commit changes
-          git add docs
-          
-          # Only proceed if there are changes to commit
-          if git diff --staged --quiet; then
-            echo "No documentation changes to commit"
-            echo "CHANGES_EXIST=false" >> $GITHUB_ENV
-            exit 0
-          else
-            git commit -m "Update documentation"
-            git push origin $BRANCH_NAME
-            echo "CHANGES_EXIST=true" >> $GITHUB_ENV
-          fi
-
-      - name: Create Pull Request
-        if: success() && env.CHANGES_EXIST == 'true'
-        run: |
-          gh pr create \
-            --base development \
-            --head $BRANCH_NAME \
-            --title "Update Documentation $(date +%Y-%m-%d)" \
-            --body "Automated documentation update from GitHub Actions
-
-          This PR updates the documentation to match the current project structure.
-          
-          Changes include:
-          - Synchronized documentation structure with main project
-          - Preserved configuration files, layouts, and assets
-          - Updated all markdown files"
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Upload the directory as an artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: docs
+          path: docs
 
   # Build job
   build:
     runs-on: ubuntu-latest
-    if: |
-      github.event_name == 'pull_request' &&
-      github.event.pull_request.merged == true
+    needs: sync
     steps:
-      - name: Checkout
-        uses: actions/checkout@v4
+      - name: Download the artifact
+        uses: actions/download-artifact@v5
         with:
-          ref: development
-          fetch-depth: 0  # Fetch all history so we have the latest changes
-      - name: Git Pull
-        run: git pull origin development  # Ensure we have the latest development branch
+          name: docs
+          path: docs
       - name: Setup Ruby
         uses: ruby/setup-ruby@v1
         with:
@@ -223,20 +179,15 @@ jobs:
 
   # Deployment job
   deploy:
+    needs: build
+    permissions:
+      pages: write      # to deploy to Pages
+      id-token: write   # to verify the deployment originates from an appropriate source
     environment:
       name: github-pages
       url: ${{ steps.deployment.outputs.page_url }}
     runs-on: ubuntu-latest
-    needs: build
-    if: |
-      github.event_name == 'pull_request' &&
-      github.event.pull_request.merged == true
-    permissions:
-      pages: write
-      id-token: write
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v3
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
+        uses: actions/deploy-pages@v4

ARCHITECTURE.md

@@ -16,15 +16,15 @@ Each `Instance` specifies a DCS executable that can be launched on that specific
 your Saved Games directory. The single instance that every server should have is DCS.release_server.
 
 Each instance has its own UDP communication port (default 6666). It will contact the DCSServerBot via UDP usually 
-over port 10042. The whole communication is UDP based. This has a slight risk of data loss, but is non-blocking
-and much faster. Very large servers run DCSServerBot. It has a small payload in DCS and only has a very small 
-performance impact on your servers.
+over port 10042. The whole communication is UDP-based. This has a slight risk of data loss, but is non-blocking
+and much faster. Huge servers run DCSServerBot. It has a small payload in DCS and only has a tiny performance impact 
+on your servers, if ever.
 
 ### Server
 Each `Server` specifies a __configuration__ that can be loaded into an instance. Even if there is usually a 1-to-1 
 connection between instances and servers, servers might be moved from one instance to another. Imagine your instance 
 providing power, availability and maybe components like TacView, LotAtc, SRS and your server configuration having a 
-name, the number of players and a password. You can easily move around that information from one Instance to another, 
+name, the number of players and a password. You can move around that information from one Instance to another, 
 even to another Node. That's why I decided to loosely couple that information and not hard code it into each node.
 
 > ❗ A standard configuration will only have one node and probably only one server.
@@ -65,10 +65,11 @@ You can find more information on how to do that [here](./services/README.md).
 `Plugins` are modules that only run on your bot. This is important to know and to understand, because they for 
 instance don't have easy access to some file system on any remote node. They communicate with any other object like
 other nodes, services on other nodes or other servers via so called `Proxies`. A proxy provides the same interface as
-the real object. If you for instance access any server object, you access the real implementation if that server is
+the real object. If you, for instance, access any server object, you access the real implementation if that server is
 running on the same node or 
 
-DCSServerBot comes with a lot of services and plugins already, that are all described in more detail in this documentation.<br>
+DCSServerBot comes with a lot of services and plugins already, that are all described in more detail in their 
+respective README-files.<br>
 You can enhance DCSServerBot by implementing your own services and / or plugins (or hybrids). You'll find a howto 
 [here](./plugins/README.md) and [here](./services/README.md). 
 
@@ -100,12 +101,9 @@ installed on a cloud drive already. This helps you to keep a single configuratio
 ### Cloud Database
 You can either host a database on one of your nodes, which creates another single point of failure, or have a cloud
 database at some of the prominent cloud services. As the bot databases don't get that large, it should not be a big 
-deal. I have one for $7 a month, running our 2 bots and 10 servers on it. That's an easy investment.
+deal. I have one for approx $7 a month, running our 2 bots and 10 servers on it. That's an easy investment.
 
 ### Automatic Fail-over
-At the moment, the bot can do automatic fail-overs for the Discord bot service. This will make sure that the bot is
-responsive on Discord at any time, even if one of your nodes crashes (prerequisite: cloud database).
-
-_It is planned, to have automatic server takeovers also. That means, if you have a very prominent server that it can
-for instance take down your development instance on another host, if needs be, and make sure the production server
-is up and running 24x7. As DCS does not support hot migration, the mission will start fresh like after a restart._
+At the moment, the bot can do automatic fail-overs for and service that is configured as a Master only service (like
+the Discord bot service). This will ensure that the bot is responsive on Discord at any time, even if one of your 
+nodes crashes (prerequisite: cloud database).

MULTINODE.md

@@ -77,8 +77,9 @@ A standard PostgreSQL installation does not allow remote access to the database.
 In addition, you would need to allow external access to your database by forwarding the database port (default: 5432)
 from your router to the PC running the database. You can also get a cloud database. There are many providers out there
 where you can rent one for relatively small money.
+> [!IMPORTANT]
 > For a secure communication, you should consider enabling SSL in your database. A howto for that would be too much
-> for this little guide, but there are lots of guides available in the web how to do that.
+> for this little guide, but there are lots of guides available on the web how to do that.
 
 ## Running multiple versions of DCS World on one PC
 One DCSServerBot node can run as many DCS servers as your PC can handle, but they all share the very same DCS World 
@@ -88,6 +89,7 @@ DCSServerBot uses the hostname of the PC as node name, if not specified otherwis
 the same PC, you need to specify an additional parameter -n (or --node) on startup (e.g. `run -n node01`).<br>
 This will start a new node (you'll be prompted for the installation of it, if it does not exist yet), with the name
 "node01". 
+> [!IMPORTANT]
 > The node-name has to be unique in your **whole cluster**.
 
 ## Running multiple Nodes on multiple PCs
@@ -129,6 +131,7 @@ what the bot will create during a default installation also.
 
 ### Moving a Server from one Node / Instance to another
 Each server is loosely coupled to an instance on a node. You can migrate a server to another instance though, by using
-the `/server migrate` command. Please keep in mind that - unless you use a central missions directory - the necessary
-missions (or scripts) for this server might not be available on the other node and the migration will end up in a state
-that you had not planned.
+the `/server migrate` command. 
+> [!NOTE]
+> Unless you use a central missions directory, the necessary missions (or scripts) for this server might not be 
+> available on the other node and the migration will end up in an incomplete state.