Revisit how we determine files-changed
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 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分
- マージ済み PR（30日）
- 15
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
taskcluster/taskgraph のほかの issue
-
Dependency Dashboard オープン
難易度 5/5 1週間以上 初心者へのやさしさ 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 1週間以上 初心者へのやさしさ 35/100
taskcluster/taskgraph#865 · コメント 1 件 ·
taskcluster/taskgraph の issue をすべて見る
似ている issue
-
essnmx good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 95/100
-
[Feature] 奇物选择添加优先级 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
syfoud/Simulated_Scepter#174 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Giskard-AI/giskard-oss#2840 · コメント 1 件 ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success オープンarea: repo bug perceived difficulty: 2
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
yeti-platform/yeti#1380 ·