ci: do not trigger Build on PR description edits

[raiden00pl]

Summary

The Depends-On feature (commit 2aebae7) made the Build workflow
trigger on PR description edits. A gate job checks whether the edit
changed any Depends-On declaration: if yes, the build jobs run again
with the new dependencies; on any other edit the gate skips all build
jobs.

The gate has a side effect that breaks PR check results. Skipped jobs
still register check results on the PR, and the PR checks view shows
the newest check run of each name. So after any description edit the
PR shows "skipped" for every build check instead of the pass/fail
from the real run. Re-running that newest run only repeats the skip,
so the real results never come back. This can also hide a red X from
a failed build.

Fix by not triggering Build on description edits at all: remove the
"edited" event type and the gate job.

Depends-On keeps working: dependencies are read from the description
at the start of every run against master, as before. Fetch-Source now
re-reads the description through the API instead of using the copy
stored in the event payload, so every run uses the current Depends-On
state no matter how it was triggered.

After editing a Depends-On line, retrigger CI by any of:
- pushing new or rebased commits to the PR branch
- closing and reopening the PR
- pressing "Re-run all jobs" on the existing Build run

A description edit alone no longer triggers anything, which is
exactly the behavior that corrupted the PR check results.

Impact

try to fix #3690 (comment)

Testing

none, must be checked upstream

[Abhishekmishra2808]

Thanks. Please rebase this onto the current master (including #3727) and re-run CI.

[zhangning21]

Thanks for catching this and for the quick fix, @raiden00pl. Sorry for the breakage — the gate job was my addition in #3690 and I clearly missed this failure mode.

Your analysis is exactly right: skipped jobs still register check results, and since the PR checks view shows the newest run per check name, any description edit replaced the real pass/fail with "skipped". The part that worries me most is the one you called out — it can mask a red X from a failed build. That makes the gate strictly worse than not having it at all.

The fix looks right to me, and I don't think there is a smarter variant: GitHub has no workflow-level conditional, so once on: matches, the run is created and every job in it reports a check run, skipped ones included. Not listening for edited at all is the only thing that actually removes the problem.

Re-reading the description through the API in Fetch-Source also fixes a latent bug in my original version: a manual "Re-run all jobs" used the body from the event payload, so an edited Depends-On line was silently ignored on re-run.

I see you already opened apache/nuttx#19855 for the same fix on the OS side — thanks for doing both. Looks good to me. Merging both should get CI back to normal.

Two things worth writing down, since the behaviour changes for authors:

1. Editing the description no longer triggers anything, and nothing reports that. depends-on-comment.yml runs on Build completion, so a changed Depends-On line now produces no comment and no warning at all. Retriggering needs a push, a close/reopen, or "Re-run all jobs" — and "Re-run failed jobs" is not enough, because it does not rerun a Fetch-Source job that already succeeded. For contributors pushing from a fork, only push and close/reopen are available; re-running needs write access.
2. Changing the base branch no longer triggers a Build either. That matters here because a release/backport base ignores Depends-On, so a green result produced with dependencies applied can survive a base change to a release branch.

One follow-up that is missing: Documentation/testing/nuttx-ci.rst still describes the old behaviour ("Editing the pull request description triggers the CI dependency gate..."), and apache/nuttx#19855 does not update it. I am happy to send that documentation patch — either as a commit on your PR or as a follow-up, whichever you prefer.

[cederom]

Thank you @raiden00pl :-)

[cederom]

Ugh, CI failed :-(