feat: support specifying nested samples in east.yml

Closes: #111

CHANGELOG.md

@@ -6,6 +6,16 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ## [Unreleased]
 
+### Added
+
+-   `east.yml` now supports specifying samples in nested subdirectories. For example, if there is a
+    sample located under `samples/basic/blinky`, it can be specified in `east.yml` simply as
+    `- name: basic/blinky`. Samples build artefacts will be stored in the `build` directory under
+    the same subdirectory structure. This feature allows users to organize their samples in a more 
+    structured way, instead of having all samples in the root `samples` directory.
+    This feature is documented in the `docs/configuration.md` file under `Samples` section.
+    Suggested by @Finwood in #111.
+
 ### Fixed
 
 -   `east release` command, which failed to find project dir, when run with 

docs/configuration.md

@@ -234,6 +234,31 @@ samples:
     # Don't inherit, use default west behaviour in the `dfu` sample folder
 ```
 
+### Nested samples
+
+`samples` folder can contain nested sub-folders with samples.
+
+For example, if we have a `blinky` sample located like this:
+
+```text
+example_project
+├── samples
+│   ├── basic
+│   │   ├── blinky   # Blinky sample
+```
+
+then you would specify such sample in `east.yml` like this:
+
+```yaml
+samples:
+  - name: basic/blinky
+    west-boards:
+      - custom_nrf52840dk
+    inherit-build-type:
+      app: nrf52_app
+      build-type: debug
+```
+
 ## Release command
 
 `east release` command runs a release process consisting of a series of
@@ -253,9 +278,10 @@ for a specific key will be skipped, if it is not present.
 Different hardware versions of listed boards are picked up automatically from
 the `board` directory.
 
-Created binaries are named according to the [IRNAS's release artefact naming
-guidelines]. Samples are placed into a separate folder to avoid confusion. A
-collection of zip files is created to simplify upload to GitHub Release page.
+Created binaries are named according to the [IRNAS's release artefact
+naming guidelines]. Samples are placed into a separate folder to avoid
+confusion. A collection of zip files is created to simplify upload to GitHub
+Release page.
 
 High-level release process looks like this:
 
@@ -299,8 +325,8 @@ In both cases the file extensions are preserved.
 This document assumes knowledge of several different concepts:
 
 - [Kconfig documentation page] - the main page about KConfig
-- [One time CMake Arguments] - How to specify additional conf files to `Cmake`,
-  `east` uses that under the hood
+- [One time CMake Arguments] - How to specify additional conf files to `Cmake`, `east`
+  uses that under the hood
 - [Nice blog about Zephyr configuration]
 
 [irnas's release artefact naming guidelines]:

src/east/workspace_commands/release_commands.py

@@ -44,6 +44,10 @@ def create_artefact_name(project, board, version, build_type):
     We also add git hash at the end if the build was not done on the clean tagged
     commit.
     """
+    # As we allow project names to be paths for samples, we need to extract just the
+    # name of the project.
+    project = os.path.basename(project)
+
     board = board.replace("@", "-hv")
 
     # "Normalize" hw v2 board names
@@ -434,10 +438,9 @@ def release(east, dry_run, verbose, spdx_app_only):
         else:
             app["build-types"] = [{"type": None}]
 
-    samples_in_dir = os.listdir("samples") if os.path.isdir("samples") else []
     for sample in samples:
         # Check, if the sample even exists before building for it
-        if sample["name"] not in samples_in_dir:
+        if not os.path.isdir(os.path.join("samples", sample["name"])):
             east.print(non_existing_sample_msg_fmt(sample["name"]))
             east.exit()
         # Add parent to mark from where this key comes from