使用GitHub CLI、Git结合GitHub Actions时结果不稳定的问题排查

我编写了一个Shell脚本，用于基于关键词检查仓库中是否存在指定分支，脚本片段如下：

for repo_name in ${repository[@]}; do
  gh repo clone $org_name/$repo_name >/dev/null 2>&1
  cd $repo_name
  if [[ -n "$(git branch -r | grep -w $keyword)" ]]; then
    echo "Branch does exist in $org_name/$repo_name"
  else
    echo "Branch does not exist in $org_name/$repo_name"
  fi
  cd ..
  rm -rf $repo_name
done

同时我用GitHub Actions工作流持续执行该脚本。测试名为ABC的分支时，本地运行正常，能正确识别仓库R1、R2都存在ABC分支；但在仓库R3的工作流中，检测R2时显示该分支不存在，而新建仓库R4使用完全相同的脚本和工作流，结果却和本地一致（能检测到R1、R2都存在ABC分支）。

补充信息：R3和R4的工作流使用相同的私钥和GitHub Apps进行认证。

请问这种情况可能是什么原因导致的？是否和我的Shell脚本有关？

1. 脚本本身的缺陷（核心诱因） #

你的脚本依赖git branch -r检测远程分支，但gh repo clone默认只会克隆仓库的默认分支，不会自动拉取所有远程分支。刚克隆完成的仓库里，git branch -r只能看到默认分支的远程跟踪分支（比如origin/main），其他分支（比如ABC）不会被同步，这就会直接导致误判。

本地环境正常是因为你可能之前克隆过R2，或手动执行过git fetch拉取了全部分支；而R4的工作流可能刚好某次执行触发了完整拉取，或测试场景中ABC恰好是默认分支。

修复方案：

• 方案一：克隆后新增拉取全部分支的步骤

  gh repo clone $org_name/$repo_name >/dev/null 2>&1
  cd $repo_name
  git fetch --all >/dev/null 2>&1 # 新增该行拉取所有远程分支
  if [[ -n "$(git branch -r | grep -w $keyword)" ]]; then
    # 后续逻辑保持不变
  fi
  

• 方案二：无需克隆仓库，用git ls-remote直接检查（更高效准确）

  for repo_name in ${repository[@]}; do
    if git ls-remote --heads "https://github.com/$org_name/$repo_name" "$keyword" >/dev/null 2>&1; then
      echo "Branch does exist in $org_name/$repo_name"
    else
      echo "Branch does not exist in $org_name/$repo_name"
    fi
  done
  

  这个方案省去克隆仓库的步骤，既节省资源又避免分支同步问题。

2. GitHub Apps权限配置差异 #

尽管R3和R4使用相同的私钥与GitHub Apps，但要注意：GitHub Apps的权限可针对单仓库或组织范围设置。可能你的Apps在配置时，给R4所在的组织/仓库开放了访问R2的权限，但R3对应的安装实例遗漏了R2的访问权限。

比如：

• Apps设置为“仅选中仓库”，但R2未被添加到选中列表
• Apps在R3仓库安装时，权限范围未覆盖R2所在的组织

这种情况下，R3的工作流通过Apps认证后无法访问R2的分支信息，导致检测失败；而R4的工作流权限覆盖到R2，所以结果正常。

验证方式：检查GitHub Apps的安装设置，确认是否对R2仓库拥有读取内容权限，且R3对应的安装实例包含R2。

3. R3工作流的缓存/残留问题 #

R3的工作流可能开启了缓存（比如缓存克隆的仓库目录），或某次执行时rm -rf $repo_name因权限不足未完全删除目录，导致后续克隆的仓库存在旧分支信息残留，影响检测结果。而R4是新建仓库，无历史缓存，所以执行正常。

修复方式：在克隆前先强制删除目标目录，避免残留

rm -rf $repo_name # 克隆前先删除，防止残留旧内容
gh repo clone $org_name/$repo_name >/dev/null 2>&1

4. 环境变量解析异常 #

检查R3工作流中$keyword变量的赋值是否正确，比如是否存在空格、特殊字符被转义的情况，导致grep -w无法匹配到正确的分支名。例如若$keyword被错误解析为AB C（带空格），自然匹配不到ABC分支。

验证方式：在脚本中增加echo "当前检测关键词: $keyword"输出变量值，对比R3和R4工作流的输出，确认变量一致。

内容的提问来源于stack exchange，提问作者Tony Chan