Revisit how we determine files-changed
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- git, github, python
- 领域
- build-system, ci-cd, devops
调研方向
Start in src/taskgraph/decision.py around the linked logic that determines the base revision and files-changed, then review how shallow clones affect git merge-base. Compare the proposed diff-based and GitHub API approaches for force pushes, new branches, and pull requests; done means choosing and implementing a solution with defined files-changed behavior for these cases.
由索引模型根据 Issue 内容生成。
描述
Problem
Taskgraph currently does some extra logic to figure out a proper base revision that we then use to compute the files changed by the graph:
https://github.com/taskcluster/taskgraph/blob/99840c4b0405ebeb7777b466df779b79b5612078/src/taskgraph/decision.py#L202
This logic is solving some deficiencies with Github events:
- For force pushes, the
event.beforeis the newly orphaned head rather than the actual base revision. - For pushes to new branches, the
event.beforeis the null revision - For pull requests, the
pull_request.base.shaproperty contains the revision that the base reference currently points to, not the revision that the PR is based on.
So instead, we essentially use git merge-base <default branch> <head rev> to find the ancestor commit of both, and then set that to the base revision, which then gets used to compute files-changed.
The problem is that now we're starting to use shallow clones, which means that merge-base doesn't work without progressively deepening the repository until we find the ancestor (negating the benefit of shallow clones).
So a new solution is needed!
Possible Solutions
Simply stop using git merge-base
In this solution, we would simply run git diff <base> <head> to get the files modified between the two trees. Here we would be consciously making a tradeoff of sometimes having inaccurate files-changed for simplicity and clone performance. The above scenarios would roughly shake out like:
files-changedwould include files that were modified by orphaned commits under<base>, even if<head>didn't touch them. This would cause us to run more tasks than necessary.- We'd probably have to special case this, maybe only looking at files touched by
<head>. - Pull requests would have files-changed that are derived from all commits on the base branch that the PR hasn't rebased on top of yet, potentially running many more tasks than expected
Use the Github API
It should be possible to get the files modified from a PR or force push using the Github API. This would be fast and simple to implement, though we'd need to start worrying about rate limits, tokens and it isn't portable if we ever want to support non-Github repos.
In this case, we'd likely still want a fallback to the merge-base solution for non-Github repos or when hitting rate limits.
- 主要语言
- Python
- 星标
- 26
- 派生
- 55
- 平均合并
- 2 天 6 分钟
- 30 天内合并 PR
- 15
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
taskcluster/taskgraph 的其他 Issue
-
难度 5/5 一周以上 新手友好度 20/100
taskcluster/taskgraph#952 ·
-
难度 4/5 3-5 天 新手友好度 35/100
taskcluster/taskgraph#915 ·
-
feature
难度 3/5 1-2 天 新手友好度 35/100
taskcluster/taskgraph#911 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 45/100
taskcluster/taskgraph#882 ·
-
难度 5/5 一周以上 新手友好度 35/100
taskcluster/taskgraph#865 · 1 条评论 ·
查看 taskcluster/taskgraph 的全部 Issue
相似的 Issue
-
area: harness bug status: needs-triage
难度 2/5 1-3 小时 新手友好度 75/100
Human-Agent-Society/reef#625 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 1/5 1 小时以内 新手友好度 80/100
learningequality/kolibri#15351 · 2 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
Name consistency 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
eellak/triplestore#65 · 1 条评论 ·