Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Revisit how we determine files-changed

Đang mở
#808 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
git, github, python
Lĩnh vực
build-system, ci-cd, devops

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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:

  1. For force pushes, the event.before is the newly orphaned head rather than the actual base revision.
  2. For pushes to new branches, the event.before is the null revision
  3. For pull requests, the pull_request.base.sha property 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:

  1. files-changed would 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.
  2. We'd probably have to special case this, maybe only looking at files touched by <head>.
  3. 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.

Ngôn ngữ chính
Python
Star
26
Fork
55
Merge trung bình
2 ngày 6 phút
Pull request đã merge (30 ngày)
15

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của taskcluster/taskgraph

Tất cả issue của taskcluster/taskgraph

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.