all: Fix broken links and add GitHub Actions workflow for link checking

.github/workflows/ci.yml

@@ -186,3 +186,18 @@ jobs:
     - uses: actions/checkout@v4
     - name: Spell Check Repo
       uses: crate-ci/typos@master
+
+  linkChecker:
+    name: link checker
+    permissions:
+      contents: read
+    if: github.repository == 'containerd/runwasi'
+    timeout-minutes: 15
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - uses: lycheeverse/lychee-action@f613c4a64e50d792e0b31ec34bbcbba12263c6a6 # v2.3.0
+      with:
+        fail: false # don't fail the build on broken links
+        format: markdown
+        jobSummary: true

.github/workflows/docs.yml

@@ -42,3 +42,47 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_dir: ./docs/book
           keep_files: true
+
+  post_deploy_link_check:
+    name: Verify links after deployment
+    needs: [deploy]
+    if: ${{ github.ref == 'refs/heads/main' }}
+    permissions:
+      contents: read
+      issues: write
+    timeout-minutes: 15
+    runs-on: ubuntu-latest
+    steps:
+      - name: Wait for GitHub Pages to update
+        run: sleep 120
+      - name: Check all links on runwasi.dev
+        uses: lycheeverse/lychee-action@f613c4a64e50d792e0b31ec34bbcbba12263c6a6 # v2.3.0
+        with:
+          fail: true # Fail CI if broken links found on the live site
+          format: markdown
+          jobSummary: true
+
+      - name: Setup GitHub CLI
+        if: ${{ failure() }}
+        uses: cli/setup-gh@v1
+
+      - name: Create or update issue on link check failure
+        if: ${{ failure() }}
+        shell: bash
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          TODAY=$(date +"%Y-%m-%d")
+          EXISTING_ISSUE=$(gh issue list --repo ${{ github.repository }} --label broken-links --state open --json number --jq ".[0].number")
+          ISSUE_BODY="# Broken Links Report ($TODAY)
+
+          The post-deployment link check has detected broken links on the runwasi.dev website. 
+          Please see the [link checker workflow run](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}) for details.
+
+          > This issue was automatically generated from the link checker workflow."
+
+          if [ -n "$EXISTING_ISSUE" ]; then
+            gh issue comment $EXISTING_ISSUE --repo ${{ github.repository }} --body "New broken links were detected in the workflow run on $TODAY. Please check the latest workflow run for details: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}"
+          else
+            gh issue create --repo ${{ github.repository }} --title "Broken links detected on runwasi.dev" --body "$ISSUE_BODY" --label documentation --label broken-links
+          fi

CONTRIBUTING.md

@@ -9,7 +9,7 @@ which apply to all containerd projects.
 
 ## Setting up your local environment
 
-At a minimum, the Rust toolchain.  When using `rustup` the correct toolchain version is picked up from the [rust-toolchain.toml](./rust-toolchain.toml) so you don't need to worry about the version.
+At a minimum, the Rust toolchain.  When using `rustup` the correct toolchain version is picked up from the [rust-toolchain.toml](https://github.com/containerd/runwasi/blob/main/rust-toolchain.toml) file so you don't need to worry about the version.
 
 > ```
 > curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@@ -29,7 +29,7 @@ If on Windows use (use [git BASH](https://gitforwindows.org/) terminal which has
 ./scripts/setup-windows.sh
 ```
 
-If you choose to always build with `cross`, you don't need any of these requirements above as they will be provided via the cross container.  This does require `docker` or `podman`. Refer to the [cross getting started page](https://github.com/cross-rs/cross/wiki/Getting-Started) for more details. 
+If you choose to always build with [cross](https://github.com/cross-rs/cross), you don't need any of these requirements above as they will be provided via the cross container.  This does require `docker` or `podman`. Refer to the [cross getting started page](https://github.com/cross-rs/cross/wiki/Getting-Started) for more details. 
 
 Install cross:
 
@@ -39,7 +39,7 @@ scripts/setup-cross.sh
 
 ## Project structure and architecture
 
-For a detailed overview of the Runwasi structure and architecture, please refer to the [Architecture Documentation](./docs/src/user-guide/architecture.md).
+For a detailed overview of the Runwasi structure and architecture, please refer to the [Architecture Documentation](https://runwasi.dev/developer/architecture.html).
 
 The documentation covers:
 - High-level structure of Runwasi
@@ -61,7 +61,7 @@ To build a shim for specific runtime (wasmtime, wasmer, wasmedge, wamr, etc):
 make build-<runtime>
 ```
 
-By default the runtimes will build for your current OS and architecture.  If you want to build for a specific OS and architecture you can specify `TARGET`, where it matches a target in [Cross.toml](./Cross.toml). If your target doesn't match your host OS and architecture [Cross](https://github.com/cross-rs/cross) will be used. As an example will build a static binary:
+By default the runtimes will build for your current OS and architecture.  If you want to build for a specific OS and architecture you can specify `TARGET`, where it matches a target in "Cross.toml". If your target doesn't match your host OS and architecture [Cross](https://github.com/cross-rs/cross) will be used. As an example will build a static binary:
 
 ```
 TARGET=x86_64-unknown-linux-musl make build
@@ -71,7 +71,7 @@ TARGET=x86_64-unknown-linux-musl make build
 
 ### Unit tests
 
-Unit tests are run via `make test`  or for a specific runtime `make test-<runtime>`. On linux the tests will run using `sudo`. This is configured in the `runner` field in [.cargo/config.toml](./.cargo/config.toml)
+Unit tests are run via `make test`  or for a specific runtime `make test-<runtime>`. On linux the tests will run using `sudo`. This is configured in the `runner` field in ".cargo/config.toml"
 
 You should see some output like:
 ```terminal
@@ -90,9 +90,9 @@ RUST_LOG=DEBUG cargo test --package containerd-shim-wasmtime --lib -- wasmtime_t
 
 ### End to End tests
 
-The e2e test run on [k3s](https://k3s.io/) and [kind](https://kind.sigs.k8s.io/).  A test image is built using [oci-tar-builder](./crates/oci-tar-builder/) and is loaded onto the clusters.  This test image is not pushed to an external registry so be sure to use the Makefile targets to build the image and load it on the cluster.
+The e2e test run on [k3s](https://k3s.io/) and [kind](https://kind.sigs.k8s.io/).  A test image is built using [oci-tar-builder](https://github.com/containerd/runwasi/tree/main/crates/oci-tar-builder) and is loaded onto the clusters.  This test image is not pushed to an external registry so be sure to use the Makefile targets to build the image and load it on the cluster.
 
-The deployment file in [test/k8s/Dockerfile](./test/k8s/Dockerfile) is run and verified that it deploys and runs successfully.  To execute the e2e tests in either kind or k3s:
+The deployment file in [test/k8s/Dockerfile](https://github.com/containerd/runwasi/blob/main/test/k8s/Dockerfile) is run and verified that it deploys and runs successfully.  To execute the e2e tests in either kind or k3s:
 
 ```
 make test/k8s-<runtime> # runs using kind
@@ -107,7 +107,7 @@ make test/k8s-oci-<runtime>
 
 ### Building the test image
 
-This builds a [wasm application](crates/wasi-demo-app/) and packages it in an OCI format:
+This builds a [wasm application](https://github.com/containerd/runwasi/tree/main/crates/wasi-demo-app/) and packages it in an OCI format:
 
 ```
 make test-image
@@ -133,7 +133,7 @@ Most features will likely have most of the code in the `containerd-shim-wasm` pr
 
 A tip for developing a new feature is to implement it and test it with one runtime you are familiar with then add it to all the runtimes.  This makes it easier to test and iterate before making changes across all the runtimes.
 
-Any changes made to the `containerd-shim-wasm` crate needs to be documented in the [CHANGELOG.md](./crates/containerd-shim-wasm/CHANGELOG.md) file following the [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format.
+Any changes made to the `containerd-shim-wasm` crate needs to be documented in the [CHANGELOG.md](https://github.com/containerd/runwasi/blob/main/crates/containerd-shim-wasm/CHANGELOG.md) file following the [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format.
 
 ## Adding new shims
 

README.md

@@ -63,4 +63,4 @@ Check out these projects that build on top of runwasi:
 
 ## Contributing
 
-To begin contributing, please read our [Contributing Guide](https://runwasi.dev/developer/contributing.html).
+To begin contributing, please read our [Contributing Guide](https://runwasi.dev/CONTRIBUTING.html).

crates/containerd-shim-wasmtime/README.md

@@ -12,7 +12,7 @@ entrypoint is specified, the shim will look for a `_start` function in the modul
 execution when the module is loaded in the runtime. The `_start` function is a WASI convention for the Command modules
 (see the [distinction between the Command and Reactors](https://github.com/WebAssembly/WASI/issues/13)).
 
-The shim adds experimental support for running [WASI Preview 2](https://github.com/WebAssembly/WASI/blob/main/preview2/README.md) components.
+The shim adds experimental support for running [WASI 0.2](https://wasi.dev/interfaces#wasi-02) Wasm components.
 If no entrypoint is specified, the shim will assume that the WASI component is a component that uses the [wasi:cli/command](https://github.com/WebAssembly/wasi-cli) world.
 
 

docs/src/getting-started/demos.md

@@ -119,5 +119,5 @@ sudo ctr run --rm --runtime=io.containerd.wasmedge.v1 ghcr.io/containerd/runwasi
 ## Next Steps
 
 - Explore running WebAssembly workloads on Kubernetes in the [Quickstart with Kubernetes](./quickstart.md) guide
-- Learn about the [Architecture](../user-guide/architecture.md) of Runwasi
+- Learn about the [Architecture](../developer/architecture.md) of Runwasi
 - Check out [Contributing](../CONTRIBUTING.md) to get involved with the project 

docs/src/getting-started/quickstart.md

@@ -184,5 +184,5 @@ sudo k3s kubectl delete -f deploy.yaml
 Now that you've set up Kubernetes to run WebAssembly workloads:
 
 - Learn about [OCI Integration](../oci-decision-flow.md) for container images
-- Explore [Architecture Overview](../user-guide/architecture.md) to understand how Runwasi works
+- Explore [Architecture Overview](../developer/architecture.md) to understand how Runwasi works
 - Check out [OpenTelemetry Integration](../opentelemetry.md) for monitoring your WebAssembly workloads

docs/src/resources/community.md

@@ -32,7 +32,7 @@ If you need help with Runwasi, there are several ways to get assistance:
 
 We welcome contributions of all kinds! Whether you're fixing a typo, improving documentation, adding a feature, or reporting a bug, your help is appreciated.
 
-See our [Contributing Guide](../developer/contributing.md) for detailed information.
+See our [Contributing Guide](https://runwasi.dev/CONTRIBUTING.html) for detailed information.
 
 ## Projects Using Runwasi