Doc: fix heading sentence case and language check (Infra) (#1758)

Doc: fix heading sentence case and language check

Author: tang-mm

docs/community/bugs.rst

@@ -1,6 +1,6 @@
 :orphan:
 
-Reporting Bugs
+Reporting bugs
 ==============
 
 If you have an issue with Checkbox or with the test cases coming from its

docs/explanation/configs.rst

@@ -1,6 +1,6 @@
 .. _checkbox_configs:
 
-Checkbox Configs
+Checkbox configs
 ^^^^^^^^^^^^^^^^
 
 Configuration file path

docs/explanation/release_process/canary.rst

@@ -1,36 +1,36 @@
-Canary Testing for Checkbox Edge Version: In-depth Process
+Canary testing for Checkbox edge version: in-depth process
 ==========================================================
 
 Introduction
 ------------
 
 Canary testing applies on Checkbox snaps that are released through the `edge channel <https://snapcraft.io/docs/channels>`_ in the Snap Store. New versions are built daily if changes are made in the code repository.
 
-The following sections provide a detailed walk-through of the Canary Testing process for the Checkbox Edge version, starting from snap building to the outcomes of the testing.
+The following sections provide a detailed walk-through of the canary testing process for the Checkbox Edge version, starting from snap building to the outcomes of the testing.
 
-Snap Build and Release
+Snap build and release
 -----------------------
 
-Trigger Conditions
+Trigger conditions
 ^^^^^^^^^^^^^^^^^^
 The GitHub action responsible for building the snap runs every day. However, it only triggers when the following condition is met:
 
 At least one pull request (PR) has been merged since the last edge build.
 
-Build Workflow
+Build workflow
 ^^^^^^^^^^^^^^^
 
 To monitor the build process, or to review the configuration and logs, see `the GitHub workflow <https://github.com/canonical/checkbox/actions/workflows/checkbox-snap-daily-builds.yml>`_.
 
-Post-Build Actions
+Post-build actions
 ^^^^^^^^^^^^^^^^^^
 
 Once the build is successful, the snap packages are automatically pushed to the Snap Store in the edge channel. Testers and early adopters can access the latest version through edge releases.
 
-Jenkins Monitoring and Validation
+Jenkins monitoring and validation
 ---------------------------------
 
-Snap Monitoring
+Snap monitoring
 ^^^^^^^^^^^^^^^
 
 Once the snap is published to the edge channel in the Snap Store, our Jenkins job titled ``checkbox-edge-validation-detect-new-build`` gets into action.
@@ -48,7 +48,7 @@ The specific JSON path that's being monitored for changes is:
 
 The job checks this path every minute for updates.
 
-Validation and Wait Logic
+Validation and wait logic
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Upon detecting a new snap:
@@ -57,14 +57,14 @@ Upon detecting a new snap:
 2. If any snap is missing, the job waits for an hour, periodically checking for its availability.
 3. If the snaps are available within the waiting period, the next stage of testing is initiated.
 
-checkbox-edge-canary-validation Pipeline
+checkbox-edge-canary-validation pipeline
 ----------------------------------------
 
 Upon successful snap validation, the ``checkbox-edge-canary-validation`` pipeline begins its operation.
 
 The :doc:`canary_pipeline` contains the groovy script implementing the pipeline.
 
-Testing Platforms and Specifications
+Testing platforms and specifications
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
@@ -79,12 +79,12 @@ The :doc:`validation_job_example` contains the Jenkins job definition for the am
 For a detailed look on how the job execution is carried out by all the entities in the chain,
 refer to the :doc:`validation_pipeline_execution`.
 
-Canary Test Plan Criteria
+Canary test plan criteria
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The canary test plan outlines specific tests that are imperative for the new snap's validation. The pipeline's successful conclusion is contingent upon all these tests passing on each of the mentioned platforms.
 
-Outcome and Information propagation
+Outcome and information propagation
 -----------------------------------
 
 Should the validation complete without errors, the `beta` reference in the Checkbox repository is set to point at the revision that got validated.
@@ -93,7 +93,7 @@ The `beta` branch head is then updated on GitHub.
 Conclusion
 ----------
 
-This Canary Testing process, complete from snap building to testing, ensures that every release of Checkbox in the edge channel is thoroughly vetted and stable. 
+This canary testing process, complete from snap building to testing, ensures that every release of Checkbox in the edge channel is thoroughly vetted and stable. 
 
 
 .. toctree::

docs/explanation/release_process/canary_pipeline.rst

@@ -1,6 +1,6 @@
 .. _canary_pipeline:
 
-Canary Pipeline
+Canary pipeline
 ^^^^^^^^^^^^^^^
 This is an example on how the whole pipeline can be implemented in Jenkins.
 
@@ -15,15 +15,15 @@ This is an example on how the whole pipeline can be implemented in Jenkins.
                     script {
                         parallel (
                             "Checkbox series-22 for amd64": {
-                                echo 'Running Canary on core22 amd64'
+                                echo 'Running canary on core22 amd64'
                                 build job: 'checkbox-edge-validation-core22-amd64', wait: true, propagate: true
                             },
                             "Checkbox series-22 for arm64": {
-                                echo 'Running Canary on core22 arm64'
+                                echo 'Running canary on core22 arm64'
                                 build job: 'checkbox-edge-validation-core22-arm64', wait: true, propagate: true
                             },
                             "Checkbox series-16 for amd64": {
-                                echo 'Running Canary on core16 amd64'
+                                echo 'Running canary on core16 amd64'
                                 build job: 'checkbox-edge-validation-core16-amd64', wait: true, propagate: true
                             }
 

docs/explanation/release_process/validation_pipeline_execution.rst

@@ -1,9 +1,9 @@
 Validation pipeline execution
 =============================
 
-When validating various versions of Checkbox multiple workflows are in play. Everything starts with automated creation of an Edge version.
+When validating various versions of Checkbox multiple workflows are in play. Everything starts with automated creation of an edge version.
 
-Creating new Edge version
+Creating new edge version
 -------------------------
 Every day GitHub checks for new commits that landed in the Checkbox repository,
 and if anything new landed a new version is created.
@@ -13,36 +13,36 @@ and if anything new landed a new version is created.
 
     graph TB
 
-        A[GitHub Workflow: Detect New Commits]
-        C[Mark Version as Edge and Build Snaps]
-        E{Did Snap Builds Succeed?}
-        F[Upload New Edge Version to Store]
-        G[End: Build Failed - No New Edge Version]
+        A[GitHub workflow: detect new commits]
+        C[Mark version as edge and build snaps]
+        E{Did snap builds succeed?}
+        F[Upload new edge version to store]
+        G[End: build failed - no new edge version]
 
         A --> C
         C --> E
         E -->|Yes| F
         E -->|No| G
 
 
-With new Edge version of Checkbox in the store we can start validating it.
+With new edge version of Checkbox in the store we can start validating it.
 
-Validating the Edge version
+Validating the edge version
 ---------------------------
 
-On the Certification Jenkins instance, the ``checkbox-edge-validation-detect-new-build`` job checks the store API for new Edge versions of Checkbox.
+On the Certification Jenkins instance, the ``checkbox-edge-validation-detect-new-build`` job checks the store API for new edge versions of Checkbox.
 The job is defined in the |hwcert-jenkins-jobs|_ repository.
 
 This job is also responsible for checking if all of the necessary snaps were published (for other series and architectures).
-Once confirmed, the "Canary Test Plan" is executed. It is defined in the |hwcert-jenkins-jobs|_ repository as too.
+Once confirmed, the "canary test Plan" is executed. It is defined in the |hwcert-jenkins-jobs|_ repository as too.
 
 .. mermaid::
 
     graph TB
 
-        A[Detect New Edge Version in Store]
-        B{Check if All Necessary Snaps are Published}
-        C{Run Canary Test Plan on Devices}
+        A[Detect new edge version in store]
+        B{Check if all necessary snaps are published}
+        C{Run canary test plan on devices}
         D[No changes in the repository]
         E[Move `beta` HEAD to the point at the validated revision]
 
@@ -61,39 +61,39 @@ There are multiple entities participating in the chain of validating a Checkbox
 
     sequenceDiagram
 
-        participant Pipeline as Checkbox Validation Pipeline
-        participant Jenkins as Jenkins Job
-        participant TServer as Testflinger Server
-        participant TAgent as Testflinger Agent
+        participant Pipeline as Checkbox validation pipeline
+        participant Jenkins as Jenkins job
+        participant TServer as Testflinger server
+        participant TAgent as Testflinger agent
         participant Docker as Docker container (Checkbox Controller)
         participant Device as Device Under Test
-        participant CAgent as Checkbox Agent
-        note over Device,CAgent: Same device
+        participant CAgent as Checkbox agent
+        note over Device,CAgent: same device
 
-        Pipeline->>Jenkins: Trigger Jenkins Job
+        Pipeline->>Jenkins: Trigger Jenkins job
         activate Pipeline
-        Jenkins->>TServer: Submit Testing Job
+        Jenkins->>TServer: Submit testing job
         activate TServer
-        loop Poll for Job
-            TAgent-->>TServer: Check for Available Jobs
+        loop Poll for job
+            TAgent-->>TServer: Check for available jobs
         end
         activate TAgent
-        TAgent->>Device: Provision Device & Start Checkbox Agent
-        activate Device
+        TAgent->>Device: Provision device & start Checkbox agent
+        activate device
         activate CAgent
-        TAgent->>Docker: Run Checkbox Controller
+        TAgent->>Docker: Run Checkbox controller
         activate Docker
-        Docker->>CAgent: Start Canary Test Plan
-        CAgent-->>Docker: Return Test Results
+        Docker->>CAgent: Start canary test plan
+        CAgent-->>Docker: Return test results
         deactivate CAgent
-        Docker-->>TAgent: Report Results
+        Docker-->>TAgent: Report results
         deactivate Docker
-        TAgent-->>TServer: Job Completion Status
+        TAgent-->>TServer: Job completion status
         deactivate TAgent
-        TServer-->>Jenkins: Inform Jenkins of Outcome
+        TServer-->>Jenkins: Inform Jenkins of outcome
         deactivate TServer
-        Jenkins-->>Pipeline: Update Pipeline with Job Outcome
-        deactivate Pipeline
+        Jenkins-->>Pipeline: Update pipeline with job outcome
+        deactivate pipeline
 
 .. add code format to link text
 .. |hwcert-jenkins-jobs| replace:: ``hwcert-jenkins-jobs``

docs/explanation/understanding.rst

@@ -13,7 +13,7 @@ between the following entities:
 - provider
 - launcher
 
-Test Command
+Test command
 ------------
 
 Automated and some interactive tests use external commands to help determine the
@@ -27,7 +27,7 @@ The command returns 0 on success (ping came back), and 1 if the ping timed out.
 Let's turn this simple command into a Checkbox test.
 
 
-Job Unit
+Job unit
 --------
 
 The command from the above paragraph can now be used in a Job Unit::
@@ -47,7 +47,7 @@ Notice how the command field is a straight copy-paste of the Test Command
 
 See :ref:`units` for :ref:`more info on job units <job>`
 
-Test Plan
+Test plan
 ---------
 
 When Checkbox is run from the command line without any parameters, i.e.::

docs/how-to/agent-service.rst

@@ -1,4 +1,4 @@
-Checkbox Agent Systemd Service
+Checkbox Agent systemd service
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Checkbox snaps supporting Checkbox Remote functionality usually come with a

docs/how-to/freeze-checkbox-version.rst

@@ -1,8 +1,8 @@
 =================================
-How to Freeze a Checkbox Version
+How to freeze a Checkbox version
 =================================
 
-How to freeze Checkbox Snaps
+How to freeze Checkbox snaps
 ============================
 
 
@@ -47,11 +47,11 @@ snap.
    checkbox    3.3.0-dev19    5224   22.04/stable   ce-certification-qa  classic
    checkbox22  3.3.0-dev19    726    latest/stable  ce-certification-qa  -
 
-How to freeze Checkbox Debs
+How to freeze Checkbox debs
 ============================
 
-Using Ubuntu Snapshot Service (20.04 or later)
-----------------------------------------------
+Using Ubuntu snapshot service (20.04 LTS or later)
+--------------------------------------------------
 
 To freeze the Checkbox version of a deb package we will make use of the `Ubuntu
 Snapshot Service <https://snapshot.ubuntu.com/>`_. This service allows you to
@@ -66,10 +66,10 @@ LTS(with ``apt`` 2.4.11).
 Enable the snapshot service
 ```````````````````````````
 
-For Ubuntu 24.04
-''''''''''''''''
+For Ubuntu 24.04 LTS
+''''''''''''''''''''
 
-The ``apt`` included in Ubuntu 24.04 and later automatically detects when snapshots
+The ``apt`` included in Ubuntu 24.04 LTS (Noble) and later automatically detects when snapshots
 are supported for a repository and are enabled by default.
 
 Nevertheless, for PPAs in Launchpad it is sometimes necessary to modify the URI
@@ -121,15 +121,15 @@ Snapshot ID to most ``apt`` or ``apt-get`` commands with ``--snapshot [Snapshot
    $ apt install checkbox-ng --snapshot 20240416T000000Z
 
 
-Using a specific Snapshot ID for all apt commands
+Using a specific snapshot ID for all apt commands
 `````````````````````````````````````````````````
 
 It is possible to set apt to use a particular snapshot for all apt
 commands of a PPA repository. To do this, the specific Snapshot ID (e.g.
 20240416T000000Z) can be used in place of “yes” in the relevant source.
 
-For Ubuntu 24.04
-''''''''''''''''
+For Ubuntu 24.04 LTS
+''''''''''''''''''''
 
 .. code-block:: text
    
@@ -150,13 +150,13 @@ For Ubuntu 23.10 and earlier
    deb [snapshot=20240416T000000Z] https://ppa.launchpadcontent.net/~checkbox-dev/beta/ubuntu jammy main
 
 
-Disable Snapshot Service for a repository
+Disable snapshot service for a repository
 `````````````````````````````````````````
 
-For Ubuntu 24.04
-''''''''''''''''
+For Ubuntu 24.04 LTS
+''''''''''''''''''''
 
-For Ubuntu 24.04 and later, snapshots are enabled automatically for supported
+For Ubuntu 24.04 LTS and later, snapshots are enabled automatically for supported
 repositories. If you want to disable them for the Checkbox repository, edit the
 sources file To include ``Snapshot: no``.
 
@@ -178,10 +178,10 @@ On Ubuntu 23.10 and earlier the included version of apt did not automatically
 detect snapshot support, so snapshots should not be enabled unless you have
 added ``[snapshot=yes]`` to the relevant source.
 
-Using snapshots for 18.04 or earlier
-------------------------------------
+Using snapshots for 18.04 LTS or earlier
+-----------------------------------------
 
-The Ubuntu Snapshot Service is available for 18.04 (Bionic) and 16.04 (Xenial)
+The Ubuntu Snapshot Service is available for 18.04 LTS (Bionic) and 16.04 LTS (Xenial)
 but the apt version included does not support the ``--snapshot`` option. In this
 case, it is required to set up manually the URL in your sources to point to a
 specific snapshot. This option is also possible for later versions of Ubuntu.