Merge pull request #51 from aliceinwire/gohugo

docs: Fix puntuation with double spaces

docs/_index.md

@@ -4,8 +4,8 @@ date = 2024-01-14T07:07:07+01:00
 description = 'Tool for interact programmatically with KernelCI instances.'
 +++
 
-kci-dev is a cmdline tool for interact with a enabled KernelCI server
-Purpose of this tool to provide a easy way to use features of KernelCI Pipeline instance.
+kci-dev is a cmdline tool for interact with a enabled KernelCI server.  
+Purpose of this tool to provide a easy way to use features of KernelCI Pipeline instance.  
 
 ## Installation
 
@@ -32,7 +32,9 @@ kci-dev searches for and loads a configuration file in the following order of pr
 2) The user-specific configuration file at ~/.config/kci-dev/kci-dev.toml
 3) A site-specific configuration file, which is .kci-dev.toml by default, but can be overridden with the --settings option. 
 
-Priority: The configuration files are loaded in the order listed above, with each subsequent file overriding the settings from the previous one. If a user-specific file is present, it will override the global configuration. The site-specific file, whether default or specified by --settings, takes precedence over both the global and user-specific configuration files.
+Priority: The configuration files are loaded in the order listed above, with each subsequent file overriding the settings from the previous one.  
+If a user-specific file is present, it will override the global configuration.  
+The site-specific file, whether default or specified by --settings, takes precedence over both the global and user-specific configuration files.  
 
 ```toml
 default_instance="local"
@@ -53,11 +55,11 @@ api="https://kernelci-api.westus3.cloudapp.azure.com/"
 token="example"
 ```
 
-Where `default_instance` is the default instance to use, if not provided in the command line.
-In section `local`, `staging`, `production` you can provide the host for the pipeline, api and also a token for the available instances.
-pipeline is the URL of the KernelCI Pipeline API endpoint, api is the URL of the new KernelCI API endpoint, and token is the API token to use for authentication.
-If you are using KernelCI Pipeline instance, you can get the token from the project maintainers.
-If it is a local instance, you can generate your token using [kernelci-pipeline/tools/jwt_generator.py](https://github.com/kernelci/kernelci-pipeline/blob/main/tools/jwt_generator.py) script.
+Where `default_instance` is the default instance to use, if not provided in the command line.  
+In section `local`, `staging`, `production` you can provide the host for the pipeline, api and also a token for the available instances.  
+pipeline is the URL of the KernelCI Pipeline API endpoint, api is the URL of the new KernelCI API endpoint, and token is the API token to use for authentication.  
+If you are using KernelCI Pipeline instance, you can get the token from the project maintainers.  
+If it is a local instance, you can generate your token using [kernelci-pipeline/tools/jwt_generator.py](https://github.com/kernelci/kernelci-pipeline/blob/main/tools/jwt_generator.py) script.  
 
 ## Options
 

docs/checkout.md

@@ -4,7 +4,8 @@ date = 2024-01-14T07:07:07+01:00
 description = 'This command allow to test arbitary commit on the KernelCI Pipeline instance.'
 +++
 
-This command allow to test arbitary commit on the KernelCI Pipeline instance. This might be useful in several cases:
+This command allow to test arbitary commit on the KernelCI Pipeline instance.  
+This might be useful in several cases:
 - You want to test a specific commit, if it fails or pass test, or introduce any other degradation comparing to the current, or another commit.
 - You want to create snapshot of the test results on specific tags (releases, etc).
 - Use this command for regression bisection
@@ -156,7 +157,8 @@ Node 6707bc74322a7c560a1a38f6 job baseline-nfs-arm64-qualcomm State done Result
 Node 6707bc75322a7c560a1a38f7 job baseline-nfs-arm64-qualcomm State running Result None
 ```
 
-The command will keep watching the progress of the test until all jobs are done. You can also stop the watching by pressing `Ctrl+C` or command will stop after all jobs are done(or failed).
+The command will keep watching the progress of the test until all jobs are done.  
+You can also stop the watching by pressing `Ctrl+C` or command will stop after all jobs are done(or failed).
 
 ### --test
 
@@ -171,6 +173,8 @@ For example:
 kci-dev.py checkout --giturl https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --branch master --tipoftree --jobfilter baseline-nfs-arm64-qualcomm --jobfilter kbuild-gcc-12-arm64-chromeos-qualcomm --platformfilter sc7180-trogdor-kingoftown --watch --test crit
 ```
 
-This command will wait for the test results of the test with the name `crit`. It will follow first jobs, such as `checkout`, `kbuild-gcc-12-arm64-chromeos-qualcomm`, `baseline-nfs-arm64-qualcomm` and when they are complete will wait until timeout for the test `crit` to finish. If the test `crit` will pass, the command will return 0, if it will fail, the command will return 1, if any of the jobs will fail or timeout, the command will return 2.
+This command will wait for the test results of the test with the name `crit`.  
+It will follow first jobs, such as `checkout`, `kbuild-gcc-12-arm64-chromeos-qualcomm`, `baseline-nfs-arm64-qualcomm` and when they are complete will wait until timeout for the test `crit` to finish.  
+If the test `crit` will pass, the command will return 0, if it will fail, the command will return 1, if any of the jobs will fail or timeout, the command will return 2.  
 
 This command can be used for regression bisection, where you can test if the test `crit` pass or fail on the specific commit.

docs/results.md

@@ -74,16 +74,19 @@ Result sample:
  'user_groups': []}
 ```
 
-testnodeid is the node id of the test job, which you can get from the KernelCI dashboard. Usually it is hexadecimal string.
+testnodeid is the node id of the test job, which you can get from the KernelCI dashboard.  
+Usually it is hexadecimal string.  
 
-Additionally, for --nodes you can provide optional parameters --filter to filter the results by the given key and value. For example:
+Additionally, for --nodes you can provide optional parameters --filter to filter the results by the given key and value.  
+For example:
 ```sh
 ./kci-dev.py results --nodes --filter treeid=e25266f77837de335edba3c1b8d2a04edc2bfb195b77c44711d81ebea4494140 --filter kind=test
 ```
-This command will show the nodes of tests in particular tree checkout. But as you might see, there is a lot of fields you might be not
-interested in.
+This command will show the nodes of tests in particular tree checkout.  
+But as you might see, there is a lot of fields you might be not interested in.  
 
-For this we have additional option --field, that will restrict output only to specified fields. For example:
+For this we have additional option --field, that will restrict output only to specified fields.  
+For example:
 ```sh
 ./kci-dev.py results --nodes --filter treeid=e25266f77837de335edba3c1b8d2a04edc2bfb195b77c44711d81ebea4494140 --filter kind=test --field name --field result
 ```

docs/testretry.md

@@ -4,13 +4,15 @@ date = 2024-01-14T07:07:07+01:00
 description = 'Command for retry failed tests.'
 +++
 
-This command will retry the failed tests. In some cases tests may fail due to network issues, hardware problems,
-nature of test (flaky), etc. This command will retry the failed tests, and create additional test jobs for the failed tests.
-After observing the results, you can decide if test results were reliable, not, or maybe even test need improvement.
+This command will retry the failed tests.  
+In some cases tests may fail due to network issues, hardware problems, nature of test (flaky), etc.  
+This command will retry the failed tests, and create additional test jobs for the failed tests.  
+After observing the results, you can decide if test results were reliable, not, or maybe even test need improvement.  
 
 Example:
 ```sh
 kci-dev testretry --nodeid <str: testnodeid>
 ```
 
-testnodeid is the node id of the test job, which you can get from the KernelCI dashboard. Usually it is hexadecimal string.
+testnodeid is the node id of the test job, which you can get from the KernelCI dashboard.  
+Usually it is hexadecimal string.