Fix broken links in markdown files

Signed-off-by: Rina Fujino <[email protected]>

CODING_GUIDELINES.md

@@ -1,7 +1,7 @@
 # Coding Guidelines
 
 ## Code Style
-Follow [Rust coding guidelines](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md).
+Follow [Rust coding guidelines](https://doc.rust-lang.org/style-guide/index.html).
 When adding new feature or adding an API try to adhere to [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/about.html).
 Avoid using unsafe code.
 

CONTRIBUTING.md

@@ -16,7 +16,7 @@ If you are interested in contributing documentation, please note the following:
 - Doc issues are labeled with the `doc` label.
 - The thin-edge.io docs content is in the `docs/src/` directory.
 
-[How to build from source.](./docs/src/BUILDING.md)
+[How to build from source.](https://thin-edge.github.io/thin-edge.io/contribute/build/)
 
 <br/>
 <br/>

docs/internal/RELEASE.md

@@ -12,7 +12,7 @@ The following steps describes the thin-edge.io release process:
 
    **Notes**
 
-   When this PR is merged, the [autotag](.github/workflows/autotag.yml) workflow will detect the change in official version in the Cargo.toml, and then tag the commit with the new version number. This in turn triggers the [build-workflow](https://github.com/thin-edge/thin-edge.io/actions/workflows/build-workflow.yml) yet again to build the artifacts with the official version number.
+   When this PR is merged, the [autotag](/.github/workflows/autotag.yml) workflow will detect the change in official version in the Cargo.toml, and then tag the commit with the new version number. This in turn triggers the [build-workflow](https://github.com/thin-edge/thin-edge.io/actions/workflows/build-workflow.yml) yet again to build the artifacts with the official version number.
 
    During a release, the [build-workflow](https://github.com/thin-edge/thin-edge.io/actions/workflows/build-workflow.yml) will do the following:
 

docs/src/extend/software-management.md

@@ -417,5 +417,5 @@ That example exists immediately if one of the commands fails.
 
 Additional information and examples can be found from the following references:
 
-- [Package Manager Plugin API Specification](https://github.com/thin-edge/thin-edge.io/blob/main/docs/src/references/software-management-plugin-api.md).
+- [Package Manager Plugin API Specification](../references/software-management-plugin-api.md).
 - [tedge-apt-plugin (Debian APT Plugin)](https://github.com/thin-edge/thin-edge.io/tree/main/plugins/tedge_apt_plugin) written in Rust.

docs/src/start/device-monitoring.md

@@ -50,13 +50,13 @@ You can further customize the default collectd configuration by editing the foll
 /etc/collectd/collectd.conf
 ```
 
-Details about collectd plugins and their configuration can be viewed directly from the [collectd documentation](https://collectd.org/documentation/manpages/collectd.conf.5.shtml).
+Details about collectd plugins and their configuration can be viewed directly from the [collectd documentation](https://collectd.org/documentation/manpages/collectd.conf.html).
 
 However keep in mind the following points when editing the file:
 
 1. __MQTT must be enabled__.
    * %%te%% expects the `collectd` metrics to be published on the local MQTT bus.
-     Hence, you must enable the [MQTT write plugin of collectd](https://collectd.org/documentation/manpages/collectd.conf.5.shtml#plugin_mqtt).
+     Hence, you must enable the [MQTT write plugin of collectd](https://collectd.org/documentation/manpages/collectd.conf.html#plugin-mqtt).
    * The MQTT plugin is available on most distribution of `collectd`, but this is not the case on MacOS using homebrew.
      If you are missing the MQTT plugin, please recompile `collectd` to include the MQTT plugin.
      See [https://github.com/collectd/collectd](https://github.com/collectd/collectd) for details.

tests/RobotFramework/README.md

@@ -31,7 +31,7 @@ The general test suite flow is as follows:
 
 The ssh adapter uses an existing device and uses a SSH connect to run the test suite against it. In this setup, you are responsible for providing a device, container, server before the test can start.
 
-The general test suit flow is very similar to the above [Docker adapter](./SETUP.md#docker-adapter) flow, however the device creation and destroy steps are skipped.
+The general test suit flow is very similar to the above [Docker adapter](#docker-adapter) flow, however the device creation and destroy steps are skipped.
 
 The core thin-edge.io team uses some physical devices setup in a test lab to facilitate testing on real hardware. These devices are not available for public use, however make up part of the automated and exploratory testing.
 
@@ -68,11 +68,11 @@ It is assumed that you are running on either MacOS or Linux. If you are a Window
     sudo apt-get install python3 python3-pip python3-venv
     ```
 
-3. Install docker and docker-compose using [this guide](../../docs/src/developer/INSTALLING_DOCKER.md)
+3. Install docker and docker-compose using [this guide](https://thin-edge.github.io/thin-edge.io/contribute/setting-up-docker/)
 
 ### Option 2: Using the project's dev container
 
-Checkout the [dev container instructions](../../docs/src/developer/DEV_CONTAINER.md) for more details.
+Checkout the [dev container instructions](https://thin-edge.github.io/thin-edge.io/contribute/vscode-dev-containers/) for more details.
 
 ## Running the tests