.bumpversion.cfg

@@ -1,5 +1,5 @@
 [bumpversion]
-current_version = 2.5
+current_version = 2.6
 parse = (?P<major>\d+)\.(?P<minor>\d+)
 serialize = {major}.{minor}
 search = version: '{current_version}'

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -47,7 +47,7 @@ body:
       label: Relevant log output
       description: >
         Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
-      value: |
+      placeholder: |
         - Checkbox session(s) (located in `/var/tmp/checkbox-ng/sessions/`, you usually want to select the most recent one)
         
         - logs from the impacted components (e.g. `lsblk` if this is related to an issue when testing a disk...); a safe option is to install and run `sosreport` to gather as much log as possible.

.github/pull_request_template.md

@@ -1,20 +1,32 @@
 ## Description
 
+<!--
 Describe your changes here:
 
 - What's the problem solved (briefly, since the issue is where this is elaborated in more detail).
 - Introduce your implementation approach in a way that helps reviewing it well.
+-->
 
 ## Resolved issues
 
-Note the Jira/Launchpad issue(s) resolved by this PR (`Fixes|Resolves ...`).
+<!--
+Note the Jira and GitHub issue(s) resolved by this PR (`Fixes|Resolves ...`).
+Make sure that the linked issue titles & descriptions are also up to date.
+-->
 
 ## Documentation
 
-- [ ] Automated tests are included for the changed functionality in this PR. If to be merged without tests, please elaborate why.
-- [ ] Necessary documentation is provided for the changed functionality in this PR (tests are documentation, too).
+<!--
+Please make sure that...
+- Documentation impacted by the changes is up to date (becomes so, remains so).
+  - Documentation in the repository, including contribution guidelines.
+  - Process documentation outside the repository.
+- Tests are included for the changed functionality in this PR. If to be merged without tests, please elaborate why.
+-->
 
 ## Tests
 
-- [ ] Steps to follow for reviewer to run & manually test are provided.
-- [ ] A list of what tests were run and on what platform/configuration is provided.
+<!--
+- How was this PR tested? Please provide steps to follow so that the reviewer(s) can test on their end.
+- Please provide a list of what tests were run and on what platform/configuration.
+-->

.github/workflows/checkbox-stable-release.yml

@@ -11,6 +11,8 @@ jobs:
     steps:
       - name: Checkout checkbox monorepo
         uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
       - name: Edit the draft release and publish it
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/metabox.yaml

@@ -21,8 +21,10 @@ jobs:
           git diff --exit-code HEAD origin/main -- checkbox-ng metabox
           if [[ $? -eq 0 ]]
             then
+              echo "No Metabox run required."
               echo "required_run=false" >> $GITHUB_OUTPUT
             else
+              echo "Metabox run required!"
               echo "required_run=true" >> $GITHUB_OUTPUT
           fi
 

CONTRIBUTING.md

@@ -7,12 +7,10 @@ and its providers.
 
 ## General recommendations
 
-Setup your editor of choice to run
-[autopep8](https://pypi.org/project/autopep8/) on save. This helps keep
-everything passing [flake8](https://flake8.pycqa.org/en/latest/). The
-code doesn’t have to be pylint-clean, but running
-[pylint](https://www.pylint.org/) on your code may inform you about
-issues that could come up later in the review process.
+Setup your editor of choice to run [autopep8] on save. This helps keep
+everything passing [flake8]. The code doesn’t have to be pylint-clean, but
+running [pylint] on your code may inform you about issues that could come up
+later in the review process.
 
 ## Testing
 
@@ -29,8 +27,7 @@ $ sudo apt install git python3-virtualenv
 
 Prepare the development environment. If you are an external contributor and
 plan on submitting some changes, you will have to [fork the Checkbox repository
-first](https://docs.github.com/en/get-started/quickstart/fork-a-repo), and
-clone your own version locally. Otherwise:
+first], and clone your own version locally. Otherwise:
 
 ``` bash
 $ cd ~
@@ -67,14 +64,30 @@ You should now be able to run checkbox, select a test plan and run it:
 ``` bash
 (venv) $ checkbox-cli
 ```
+### Running/Testing checkbox remote
+
+By default `checkbox-cli` runs locally. If you want to run the [remote version]
+you have to activate the `checkbox-cli service` on the Machine under test:
+
+```bash
+(venv) # checkbox-cli service
+```
+> Note: Keep in mind that service has to be run as root and needs the 
+> virtual env, you may have to re-enable/activate it after a `sudo -s`
+
+Now you can run the remote command to connect to it:
+```bash
+(venv) $ checkbox-cli remote IP 
+```
+
+> Note: `service` and `remote` can both run on the same machine. 
+> in that situation, simply use `127.0.0.1`
 
 ### Writing and running unit tests for Checkbox
 
-Writing unit tests for your code is strongly recommended. For functions
-with an easily defined input and output, use
-[doctest](https://docs.python.org/3/library/doctest.html). For more
-complex units of code use the standard [unittest
-library](https://docs.python.org/3/library/unittest.html).
+Writing unit tests for your code is strongly recommended. For functions with an
+easily defined input and output, use [doctest]. For more complex units of code
+use the standard [unittest library].
 
 ### Validate the providers
 
@@ -94,9 +107,7 @@ tests for providers:
 
 ### Commit title
 
-In general, try to follow [Chris Beams’
-recommendations](https://chris.beams.io/posts/git-commit/). In a
-nutshell:
+In general, try to follow [Chris Beams’ recommendations]. In a nutshell:
 
 > -   Limit the length of the title to 50 characters
 > -   Begin title with a capital letter
@@ -119,62 +130,55 @@ Example:
 
 ### Linking a pull request to a GitHub issue
 
-See the [GitHub documentation](https://docs.github.com/en/
-issues/tracking-your-work-with-issues/linking-a-pull-
-request-to-an-issue) for more information.
+See the [GitHub documentation] for more information.
 
 ### Splitting work in separate commits if required
 
-If the changes you provide affect different parts of the project, it is
-better to split them in different commits. This helps others when
-reviewing the changes, helps investigation later on if a problem is
-found and usually helps the original developer to better explain and
-organize his/her changes.
+If the changes you provide affect different parts of the project, it is better
+to split them in different commits. This helps others when reviewing the
+changes, helps investigation later on if a problem is found and usually helps
+the original developer to better explain and organize his/her changes.
 
-For example, if you add a new screen to the Checkbox text user interface
-(TUI) and then modify Checkbox internals to work with this new screen,
-it is good to have one commit for the new screen, and one for the
-internals changes.
+For example, if you add a new screen to the Checkbox text user interface (TUI)
+and then modify Checkbox internals to work with this new screen, it is good to
+have one commit for the new screen, and one for the internals changes.
 
-Each commit should be stable, i.e. not introduce regressions or make
-tests fail. If two or more commits have to be used together, then they
-should become one commit.
+Each commit should be stable, i.e. not introduce regressions or make tests
+fail. If two or more commits have to be used together, then they should become
+one commit.
 
 ### Rework your changes
 
-Sometimes it is necessary to modify your changes (for instance after
-they have been reviewed by others). Instead of creating new commits with
-these new modifications, it is preferred to use Git features such as
-[rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) to
-rework your existing commits.
+Sometimes it is necessary to modify your changes (for instance after they have
+been reviewed by others). Instead of creating new commits with these new
+modifications, it is preferred to use Git features such as [rebase] to rework
+your existing commits.
 
 ## Merge requests
 
 ### General workflow
 
 Follow these steps to make a change to a Checkbox-related project.
 
-1. Check the [GitHub documentation](https://docs.github.com) on how to get
-   started. If you are a Checkbox contributor, you can clone the [Checkbox
-   repository](https://github.com/canonical/checkbox) directly; if you are an
-   external contributor, you will probably have to [fork the repository](https:
-   //docs.github.com/en/get-started/quickstart/fork-a-repo) first.
+1. Check the [GitHub documentation] on how to get started. If you are a
+   Checkbox contributor, you can clone the [Checkbox repository] directly; if
+you are an external contributor, you will probably have to [fork the
+repository] first.
 
 1. If you created a fork, you need to [configure Git to sync your fork with the
-   original repository.](https://docs.github.com/en/get-started/quickstart/
-   fork-a-repo#configuring-git-to-sync-your-fork-with-the-original-repository)
+   original repository.]
 
-1. Create a branch and switch to it to start working on your changes.
-   You can use any branch name, but it is generally good to include the
-   GitHub issue number it relates to as well as a quick explanation of
-   what the branch is about:
+1. Create a branch and switch to it to start working on your changes.  You can
+   use any branch name, but it is generally good to include the GitHub issue
+number it relates to as well as a quick explanation of what the branch is
+about:
 
         $ git checkout -b 123456-invalid-session-content
 
 1. Work on your changes, test them, iterate, commit your work.
 
-1. Before sending your changes for review, make sure to rebase your
-   work using the most up-to-date data from the main repository:
+1. Before sending your changes for review, make sure to rebase your work using
+   the most up-to-date data from the main repository:
 
         $ git checkout main
         # If you are a Checkbox contributor:
@@ -187,12 +191,28 @@ Follow these steps to make a change to a Checkbox-related project.
         First, rewinding head to replay your work on top of it...
         Applying: <your commits>
 
-1. [Push your changes](https://docs.github.com/en/get-started/using-git/
-   pushing-commits-to-a-remote-repository) to your GitHub repository.
+1. [Push your changes] to your GitHub repository.
 
 ### Finally...
 
 Once enough people have reviewed and approved your work, it can be merged into
 the main branch of the main repository. Ask a member of the Checkbox team to do
 this. The branch should be then shortly automatically merged. The pull request
 status will then switch to “Merged”.
+
+
+[autopep8]: https://pypi.org/project/autopep8/
+[flake8]: https://flake8.pycqa.org/en/latest/
+[pylint]: https://www.pylint.org/
+[fork the Checkbox repository first]: https://docs.github.com/en/get-started/quickstart/fork-a-repo
+[remote version]: https://checkbox.readthedocs.io/en/latest/remote.html
+[doctest]: https://docs.python.org/3/library/doctest.html
+[unittest library]: https://docs.python.org/3/library/unittest.html
+[Chris Beams’ recommendations]: https://chris.beams.io/posts/git-commit/
+[GitHub documentation]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
+[rebase]: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
+[GitHub documentation]: https://docs.github.com
+[Checkbox repository]: https://github.com/canonical/checkbox
+[fork the repository]: https://docs.github.com/en/get-started/quickstart/fork-a-repo
+[configure Git to sync your fork with the original repository.]: https://docs.github.com/en/get-started/quickstart/fork-a-repo#configuring-git-to-sync-your-fork-with-the-original-repository
+[Push your changes]: https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository

checkbox-core-snap/series16/snap/snapcraft.yaml

@@ -4,7 +4,7 @@ description: "Checkbox runtime and public providers"
 grade: stable
 confinement: strict
 
-version: '2.5'
+version: '2.6'
 
 base: core
 
@@ -84,7 +84,7 @@ parts:
 ################################################################################
 # Upstream: https://kernel.ubuntu.com/git/cking/stress-ng.git/plain/snap/snapcraft.yaml
   stress-ng:
-    source-tag: "V0.15.04"
+    source-tag: "V0.15.07"
     source-depth: 1
     plugin: make
     source: https://github.com/ColinIanKing/stress-ng.git

checkbox-core-snap/series18/snap/snapcraft.yaml

@@ -4,7 +4,7 @@ description: "Checkbox runtime and public providers"
 grade: stable
 confinement: strict
 
-version: '2.5'
+version: '2.6'
 
 base: core18
 
@@ -88,7 +88,7 @@ parts:
 ################################################################################
 # Upstream: https://kernel.ubuntu.com/git/cking/stress-ng.git/plain/snap/snapcraft.yaml
   stress-ng:
-    source-tag: "V0.15.04"
+    source-tag: "V0.15.07"
     source-depth: 1
     plugin: make
     source: https://github.com/ColinIanKing/stress-ng.git

checkbox-core-snap/series20/snap/snapcraft.yaml

@@ -4,7 +4,7 @@ description: "Checkbox runtime and public providers"
 grade: stable
 confinement: strict
 
-version: '2.5'
+version: '2.6'
 
 base: core20
 
@@ -90,7 +90,7 @@ parts:
 ################################################################################
 # Upstream: https://kernel.ubuntu.com/git/cking/stress-ng.git/plain/snap/snapcraft.yaml
   stress-ng:
-    source-tag: "V0.15.04"
+    source-tag: "V0.15.07"
     source-depth: 1
     plugin: make
     source: https://github.com/ColinIanKing/stress-ng.git

checkbox-core-snap/series22/snap/snapcraft.yaml

@@ -4,7 +4,7 @@ description: "Checkbox runtime and public providers"
 grade: stable
 confinement: strict
 
-version: '2.5'
+version: '2.6'
 
 base: core22
 
@@ -90,7 +90,7 @@ parts:
 ################################################################################
 # Upstream: https://kernel.ubuntu.com/git/cking/stress-ng.git/plain/snap/snapcraft.yaml
   stress-ng:
-    source-tag: "V0.15.04"
+    source-tag: "V0.15.07"
     source-depth: 1
     plugin: make
     source: https://github.com/ColinIanKing/stress-ng.git

checkbox-ng/checkbox_ng/__init__.py

@@ -24,5 +24,5 @@
 CheckBoxNG is a new version of CheckBox built on top of PlainBox
 """
 
-__version__ = '2.5'
+__version__ = '2.6'
 

checkbox-ng/checkbox_ng/config.py

@@ -39,13 +39,12 @@ def expand_all(path):
     return os.path.expandvars(os.path.expanduser(path))
 
 def load_configs(launcher_file=None):
-    # launcher can override the default name of config files to look for
-    # so first we need to establish the filename to look for
     configs = []
     config_filename = 'checkbox.conf'
     launcher = DefaultLauncherDefinition()
+    # launcher can override the default name of config files to look for
+    # so first we need to establish the filename to look for
     if launcher_file:
-        configs.append(launcher_file)
         generic_launcher = LauncherDefinition()
         if not os.path.exists(launcher_file):
             _logger.error(_(
@@ -68,6 +67,9 @@ def load_configs(launcher_file=None):
             config = expand_all(os.path.join(d, config_filename))
             if os.path.exists(config):
                 configs.append(config)
+    # Add config from launcher last so it gets precedence over others
+    if launcher_file:
+        configs.append(launcher_file)
     launcher.read(configs)
     if launcher.problem_list:
         _logger.error(_("Unable to start launcher because of errors:"))