Copilot commented on code in PR #474:
URL: https://github.com/apache/trafficserver-ci/pull/474#discussion_r4276718226


##########
jenkins/branch/rat.pipeline:
##########
@@ -49,11 +49,11 @@ pipeline {
                                                        retry(3) {
                                                                
checkout([$class: 'GitSCM',
                                                                        
branches: [[name: branch]],
-                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL]],
+                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL, refspec: 
"+refs/heads/${env.GITHUB_BRANCH}:refs/remotes/origin/${env.GITHUB_BRANCH}"]],

Review Comment:
   The fetch refspec is derived from `env.GITHUB_BRANCH`, while the checkout 
target is driven by `branches: [[name: branch]]`. If `branch` can differ from 
`env.GITHUB_BRANCH` (e.g., different naming format like `origin/foo`, or a 
ref/SHA depending on how this pipeline is triggered), the refspec may fetch the 
wrong ref and cause checkout failures. Consider deriving both the `branches` 
entry and the refspec from the same normalized branch-name source (or 
explicitly document/validate that `branch` and `env.GITHUB_BRANCH` are always 
identical in these branch pipelines).



##########
jenkins/branch/rat.pipeline:
##########
@@ -49,11 +49,11 @@ pipeline {
                                                        retry(3) {
                                                                
checkout([$class: 'GitSCM',
                                                                        
branches: [[name: branch]],
-                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL]],
+                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL, refspec: 
"+refs/heads/${env.GITHUB_BRANCH}:refs/remotes/origin/${env.GITHUB_BRANCH}"]],

Review Comment:
   The refspec explicitly writes to `refs/remotes/origin/...` but the remote 
name is not explicitly set in `userRemoteConfigs`. To avoid relying on plugin 
defaults (and to make the `origin` assumption explicit), set the remote `name` 
in `userRemoteConfigs` (e.g., `name: 'origin'`), or avoid hard-coding `origin` 
by keeping the destination consistent with the configured remote name.



##########
jenkins/branch/rat.pipeline:
##########
@@ -49,11 +49,11 @@ pipeline {
                                                        retry(3) {
                                                                
checkout([$class: 'GitSCM',
                                                                        
branches: [[name: branch]],
-                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL]],
+                                                                       
userRemoteConfigs: [[url: env.GITHUB_URL, refspec: 
"+refs/heads/${env.GITHUB_BRANCH}:refs/remotes/origin/${env.GITHUB_BRANCH}"]],
                                                                        // 
Branch builds normally checkout the current branch tip. If a manually
                                                                        // 
requested SHA is older than this shallow depth, checkout should fail fast
                                                                        // 
instead of falling back to a large full-history fetch.

Review Comment:
   The comment describes failures only in terms of shallow depth, but with the 
new branch-only refspec there is an additional constraint: a manually requested 
SHA must be reachable from the fetched branch ref (not just within depth). 
Updating this comment to reflect the new behavior/trade-off will help future 
maintainers understand why a SHA from another branch will now fail.



-- 
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]

Reply via email to