Dead links check workflow (#363)

* Added html-proofer to Gemfile

* Minor corrections found with http-proofer

* Added workflow for checking links

* Added missing command

* Trying to run without merging

* Push to maybe trigger action

* Minor changes and rollback last commit

.github/workflows/pages-check-links.yml

@@ -0,0 +1,38 @@
+name: pages-check-links
+
+# Controls when the workflow will run
+on:
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# A workflow run is made up of one or more jobs that can run sequentially or in parallel
+jobs:
+  # This workflow contains a single job called "build"
+  build:
+    # The type of runner that the job will run on
+    runs-on: ubuntu-latest
+
+    # Steps represent a sequence of tasks that will be executed as part of the job
+    steps:
+      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
+      - uses: actions/checkout@v3
+
+      - name: Setup Ruby
+        uses: ruby/[email protected]
+        with:
+          ruby-version: 2.7.x
+
+      - name: Setup Rubygems, Bundler, jekyll
+        run: | 
+          gem update --system --no-document
+          gem update bundler --no-document
+          gem install jekyll bundler
+          bundle install
+      
+      - name: Build jekyll website with drafts
+        run: |
+          cd docs/
+          bundle exec jekyll build --drafts
+        
+      - name: Check for broken links
+        run: bundle exec htmlproofer --log-level :debug ./_site --swap-urls '^/thundernetes/:/' --ignore-status-code 403

docs/Gemfile

@@ -22,3 +22,5 @@ gem "jekyll-relative-links", "~> 0.6.1"
 gem "jekyll-remote-theme", "~> 0.4.3"
 
 gem "just-the-docs", "~> 0.3.3"
+
+gem "html-proofer", "~> 4.3.0"

docs/Gemfile.lock

@@ -15,6 +15,8 @@ GEM
     em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0)
+    ethon (0.15.0)
+      ffi (>= 1.15.0)
     eventmachine (1.2.7)
     faraday (1.10.0)
       faraday-em_http (~> 1.0)
@@ -45,6 +47,15 @@ GEM
     html-pipeline (2.14.2)
       activesupport (>= 2)
       nokogiri (>= 1.4)
+    html-proofer (4.3.1)
+      addressable (~> 2.3)
+      mercenary (~> 0.3)
+      nokogiri (~> 1.13)
+      parallel (~> 1.10)
+      rainbow (~> 3.0)
+      typhoeus (~> 1.3)
+      yell (~> 2.0)
+      zeitwerk (~> 2.5)
     http_parser.rb (0.8.0)
     i18n (1.11.0)
       concurrent-ruby (~> 1.0)
@@ -110,11 +121,13 @@ GEM
     octokit (4.25.1)
       faraday (>= 1, < 3)
       sawyer (~> 0.9)
+    parallel (1.22.1)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (4.0.7)
     racc (1.6.0)
     rack (2.1.4.1)
+    rainbow (3.1.1)
     rake (13.0.6)
     rb-fsevent (0.11.1)
     rb-inotify (0.10.1)
@@ -144,15 +157,20 @@ GEM
       faraday (>= 0.17.3, < 3)
     terminal-table (2.0.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
+    typhoeus (1.4.0)
+      ethon (>= 0.9.0)
     tzinfo (2.0.4)
       concurrent-ruby (~> 1.0)
     unicode-display_width (1.8.0)
+    yell (2.2.2)
     zeitwerk (2.6.0)
 
 PLATFORMS
+  ruby
   x86_64-linux
 
 DEPENDENCIES
+  html-proofer (~> 4.3.0)
   jekyll (~> 4.2)
   jekyll-github-metadata (~> 2.15)
   jekyll-paginate (~> 1.1)

docs/architecture.md

@@ -12,15 +12,15 @@ This document describes the architecture of Thundernetes as well as various desi
 
 ## Goal
 
-End goal is to create a utility that will allow game developers to host their Game Server SDK ([gsdk](http://github.com/playfab/gsdk)) enabled Windows or Linux game servers on a Kubernetes cluster, either on-premise or on a public cloud provider. This utility will enable GameServer auto-scaling and GameServer allocations. With the term "allocation" we mean that pre-warmed game servers (we call this state "StandingBy") can transition into an "Active" state so that players (game clients) can connect to them. On a potential scale down, Thundernetes will never take down Active game servers or Nodes that have Active game servers running.
+End goal is to create a utility that will allow game developers to host their Game Server SDK ([gsdk](https://github.com/playfab/gsdk)) enabled Windows or Linux game servers on a Kubernetes cluster, either on-premise or on a public cloud provider. This utility will enable GameServer auto-scaling and GameServer allocations. With the term "allocation" we mean that pre-warmed game servers (we call this state "StandingBy") can transition into an "Active" state so that players (game clients) can connect to them. On a potential scale down, Thundernetes will never take down Active game servers or Nodes that have Active game servers running.
 
 We are extending Kubernetes by creating an [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). This involves creating a custom [controller](https://kubernetes.io/docs/concepts/architecture/controller/) and some [Custom Resource Definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) that describe various game server related entities to Kubernetes. We are using the open source tool [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) to scaffold our operator files which use [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime).
 
 Specifically, we have three core entities in our project, which are represented by the respective CRDs:
 
-- **GameServerBuild** ([YAML](http://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameserverbuilds.yaml), [Go](http://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserverbuild_types.go)): this represents a collection of GameServers that will run the same Pod template and can be scaled in/out within the Build (i.e. add or remove instances of them). GameServers that are members of the same GameServerBuild share the same details in their execution environment, e.g. all of them could launch the same multiplayer map or the same type of game. So, you could have one GameServerBuild for a "Capture the flag" mode of your game and another GameServerBuild for a "Conquest" mode. Or, one GameServerBuild for players playing on map "X" and another GameServerBuild for players playing on map "Y". You can, however, modify how each GameServer operates via BuildMetadata (configured on the GameServerBuild) or via environment variables.
-- **GameServer** ([YAML](http://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameservers.yaml), [Go](http://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserver_types.go)): this represents the multiplayer game server itself. Each GameServer has a single corresponding child [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/) which will run the container image containing your game server executable.
-- **GameServerDetail** ([YAML](http://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameserverdetails.yaml), [Go](http://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserverdetail_types.go)): this represents the details of a GameServer. It contains information like InitialPlayers, ConnectedPlayerCount and ConnectedPlayer names/IDs. Thundernetes creates one instance of GameServerDetail per GameServer. The reason we created this custom resource is that we don't want to overload GameServer with information. This way it can consume less memory and be more performant.
+- **GameServerBuild** ([YAML](https://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameserverbuilds.yaml), [Go](https://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserverbuild_types.go)): this represents a collection of GameServers that will run the same Pod template and can be scaled in/out within the Build (i.e. add or remove instances of them). GameServers that are members of the same GameServerBuild share the same details in their execution environment, e.g. all of them could launch the same multiplayer map or the same type of game. So, you could have one GameServerBuild for a "Capture the flag" mode of your game and another GameServerBuild for a "Conquest" mode. Or, one GameServerBuild for players playing on map "X" and another GameServerBuild for players playing on map "Y". You can, however, modify how each GameServer operates via BuildMetadata (configured on the GameServerBuild) or via environment variables.
+- **GameServer** ([YAML](https://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameservers.yaml), [Go](https://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserver_types.go)): this represents the multiplayer game server itself. Each GameServer has a single corresponding child [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/) which will run the container image containing your game server executable.
+- **GameServerDetail** ([YAML](https://github.com/playfab/thundernetes/tree/main/pkg/operator/config/crd/bases/mps.playfab.com_gameserverdetails.yaml), [Go](https://github.com/playfab/thundernetes/tree/main/pkg/operator/api/v1alpha1/gameserverdetail_types.go)): this represents the details of a GameServer. It contains information like InitialPlayers, ConnectedPlayerCount and ConnectedPlayer names/IDs. Thundernetes creates one instance of GameServerDetail per GameServer. The reason we created this custom resource is that we don't want to overload GameServer with information. This way it can consume less memory and be more performant.
 
 ## GSDK integration
 

docs/contributing.md

@@ -92,7 +92,7 @@ The follow list is only the tools related to building & developing the code for
 
 Thundernetes follows a standard GitHub pull request workflow.
 If you're unfamiliar with this workflow, read the very helpful
-[Understanding the GitHub flow](https://guides.github.com/introduction/flow/) guide from GitHub.
+[Understanding the GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) guide from GitHub.
 
 Anyone is welcome to create draft PRs at any stage of development/readiness.
 This can be very helpful, when asking for assistance, to refer to an active PR.

docs/gsdk/runlocalmultiplayeragent.md

@@ -15,7 +15,7 @@ To run LocalMultiplayerAgent to test your game servers for Thundernetes, you'll
 
 - Download latest version of LocalMultiplayerAgent from the [Releases](https://github.com/PlayFab/MpsAgent/releases) page on GitHub
 - [Install Docker Desktop on Windows](https://docs.docker.com/docker-for-windows/install/)
-- Make sure it's running on the appropriate container for the operating system your server needs (either Linux containers or Windows containers). Check the [Docker Desktop documentation on how to switch between the two operating systems](https://docs.docker.com/docker-for-windows/#switch-between-windows-and-linux-containers)
+- Make sure it's running on the appropriate container for the operating system your server needs (either Linux containers or Windows containers). Check the [Docker Desktop documentation on how to switch between the two operating systems](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-10-linux#run-your-first-linux-container)
 - Your game server image can be can be locally built or published on a container registry.
 - You should run `SetupLinuxContainersOnWindows.ps1` Powershell file which will create a Docker network called "PlayFab". This is necessary so that your containers running on a separate network namespace can communicate with LocalMultiplayerAgent, running on the host's network namespace.
 - You should properly configure your *LocalMultiplayerSettings.json* file. Below you can see a sample, included in `MultiplayerSettingsLinuxContainersOnWindowsSample.json`:

docs/howtos/hostnetworking.md

@@ -7,7 +7,7 @@ nav_order: 7
 
 # Host Networking
 
-Thundernetes supports running your GameServer Pods with host networking. In Kubernetes, enabling host networking will allow your Pods to use the host's (Node) network namespace and IP address. To register your game server Pods to use host networking, you need to provide a GameServerBuild YAML like [this](http://github.com/playfab/thundernetes/tree/main/samples/netcore/sample-hostnetwork.yaml), setting the `hostNetwork` value to true on PodSpec template. During Pod creation, Thundernetes controllers will **override** the containerPort with the value that will be assigned for the hostPort. 
+Thundernetes supports running your GameServer Pods with host networking. In Kubernetes, enabling host networking will allow your Pods to use the host's (Node) network namespace and IP address. To register your game server Pods to use host networking, you need to provide a GameServerBuild YAML like [this](https://github.com/playfab/thundernetes/tree/main/samples/netcore/sample-hostnetwork.yaml), setting the `hostNetwork` value to true on PodSpec template. During Pod creation, Thundernetes controllers will **override** the containerPort with the value that will be assigned for the hostPort. 
 
 You **have to** use the generated port when you instantiate your game server process. This is necessary since all the Pods will use the same network namespace and we want to prevent any port collisions from happening.
 

docs/quickstart/sample-openarena.md

@@ -8,12 +8,12 @@ nav_order: 2
 
 # Openarena sample
 
-This sample, located [here](https://github.com/PlayFab/thundernetes/tree/main/samples/openarena), is based on the popular open source FPS game [OpenArena](http://www.openarena.ws/smfnews.php). You can install it using this script:
+This sample, located [here](https://github.com/PlayFab/thundernetes/tree/main/samples/openarena), is based on the popular open source FPS game [OpenArena](https://openarena.ws/smfnews.php). You can install it using this script:
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/PlayFab/thundernetes/main/samples/openarena/sample.yaml
 ```
 
-To connect to an active server, you need to download the OpenArena client from [here](http://openarena.ws/download.php?view.4).
+To connect to an active server, you need to download the OpenArena client from [here](https://openarena.ws/download.php?view.4).
 
 To allocate a game server (convert its state to active) and scale your GameServerBuild, you can check [here](allocation-scaling.md).