Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Revisit how we determine files-changed

Aperta
#808 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
git, github, python
Ambito
build-system, ci-cd, devops

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
26
Fork
55
Merge medio
2g 6m
PR unite (30g)
15

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di taskcluster/taskgraph

Tutte le issue di taskcluster/taskgraph

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.