This is an automated email from the ASF dual-hosted git repository.

acassis pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx.git

commit d22a859a97f532758f654c7f75da4224563a0d9d
Author: Marco Casaroli <[email protected]>
AuthorDate: Mon Oct 19 10:21:42 2026 +0200

    Documentation/testing: Describe how CI skips merged dependencies.
    
    Say that Build and the memory report skip a depends-on PR that is
    already merged into the checkout, that they fail on a depends-on PR
    that is closed without merge, and what the comment shows.
    
    Assisted-by: Claude Code:claude-opus-5-5
    Signed-off-by: Marco Casaroli <[email protected]>
---
 Documentation/testing/nuttx-ci.rst | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/testing/nuttx-ci.rst 
b/Documentation/testing/nuttx-ci.rst
index 1fb14a9d297..42256b79887 100644
--- a/Documentation/testing/nuttx-ci.rst
+++ b/Documentation/testing/nuttx-ci.rst
@@ -154,6 +154,19 @@ commit list cannot be determined, or it causes a 
cherry-pick conflict,
 ``Fetch-Source`` fails instead of silently testing without the requested
 dependency.
 
+A dependency that is already merged is skipped. ``Fetch-Source`` reads the
+state of each dependency through the GitHub API. If the dependency is merged
+and its merge commit is in the checkout, its commits are already in the tree,
+so CI does not cherry-pick them again. Thus a ``Depends-On:`` declaration can
+stay in the description after the dependency is merged. A dependency that is
+merged into a different branch, or whose merge commit is not in the checkout,
+is applied as before. If CI cannot read the state, it also applies the
+dependency as before.
+
+A dependency that is closed without merge is an error. ``Fetch-Source`` does
+not apply it and fails. Remove the dependency from the ``Depends-On:``
+declaration, or reopen the dependency pull request.
+
 The memory footprint workflow applies the same declarations independently,
 using the same parser and apply sequence (see `Memory Footprint Tracking`_).
 
@@ -161,9 +174,10 @@ When a valid dependency report is available, the follow-up 
comment reports one
 of three outcomes:
 
 * successfully applied dependencies and their fetched head SHAs (abbreviated in
-  the comment)
+  the comment); a skipped dependency is marked "already merged, skipped"
 * a declaration from which no valid dependency could be parsed
-* valid dependencies that could not be applied and the failure reason
+* valid dependencies that could not be applied and the failure reason; a
+  dependency that is closed without merge is marked "closed without merge"
 
 The write-capable follow-up workflow does not execute fork code. It validates
 the untrusted report's structure, repository allow-list, run and current PR
@@ -257,4 +271,6 @@ The memory report applies the same ``Depends-On:`` 
declarations as the Build
 workflow (see `Pull Request Dependencies`_), so a pull request that only builds
 on top of another one is measured against a tree that compiles. The declaration
 rules and the ``master``-only gate are the same. A dependency that cannot be
-fetched or applied fails the job in both workflows.
+fetched or applied fails the job in both workflows. Both workflows skip a
+dependency that is already merged, and fail on a dependency that is closed
+without merge.

Reply via email to