zhangning21 commented on PR #19075: URL: https://github.com/apache/nuttx/pull/19075#issuecomment-4668107357
> 1. When we create a NuttX Release Branch, like https://github.com/apache/nuttx/tree/releases/12.13 It's meant to be compiled with the corresponding NuttX Apps Release Branch: https://github.com/apache/nuttx-apps/tree/releases/12.13 Do you expect any problems with the code? > 2. Release Branch will have Back-Ported PRs like this: [{bp-18485} sched/critmon: Fix CPU load stats incorrect when using SCHED_CPULOAD_… #18616](https://github.com/apache/nuttx/pull/18616) > Notice that the PR Body is cloned from the Original PR: [sched/critmon: Fix CPU load stats incorrect when using SCHED_CPULOAD_CRITMONITOR #18485](https://github.com/apache/nuttx/pull/18485) > Suppose the Original PR Body specifies `depends-on`, and it's copied into the Back-Ported PR. Won't the Back-Ported PR build incorrectly against the `depends-on` branch, instead of the correct `releases/12.13` branch? @lupyuen Thanks again — good point about release branches and backports. I've gone with the simplest and safest rule: `depends-on` is processed only for PRs whose target branch is `master`. ```bash if [ -n "$PR_BODY" ] && [ "$GITHUB_BASE_REF" = "master" ]; then # parse depends-on ... fi This avoids the backport problem without adding GitHub API calls or extra permissions. What this means: - Backport / release-branch PRs ignore depends-on entirely. If a backport PR to releases/12.13 carries a copied depends-on: line from the original master PR, CI skips it and keeps the existing release behavior: build against the matching releases/12.13 branch of the other repo. - A copied master dependency cannot be accidentally cherry-picked onto a release branch. - No GitHub API call and no pull-requests permission are needed. - push / tag handling is unchanged; that path has no PR body and is unrelated to depends-on. One limitation: this checks only the current PR's target branch. Without an API lookup, the workflow does not verify the dependency PR's own base branch, so this feature is intended for the normal master-branch cross-repo dependency case. A stricter version could query each dependency PR's base.ref and require it to match, but that would reintroduce an API call and extra permission surface. For now, restricting depends-on to PRs targeting master seems the simpler and safer trade-off. I've validated this in my test fork with a backport-style PR targeting releases/12.13 whose body contains a copied depends-on: line. The Apply depends-on PRs step is skipped and CI builds against the matching releases/12.13 branch, so the copied dependency is ignored: Validation run: https://github.com/zhn-test/nuttx/actions/runs/27262401865/job/80511061759 Please see the Apply depends-on PRs step in the Fetch-Source job. It is skipped. Any downstream build differences in my fork are unrelated to this depends-on handling. If this approach looks OK, I'll update this PR first. After this PR is reviewed and the approach is agreed, I will submit the matching `apache/nuttx-apps` PR with the same workflow update so the two workflows stay consistent. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
