FR: Support merge-check delta on PR history GUARDIAN_DIRS
- Lenguaje dominante
- Go
- Estrellas
- 26
- Forks
- 7
- Merge medio
- 1 d 1 h
- PR fusionados (30 d)
- 1
Descripción
### TL;DR
Current merge-check does not check the history of all PRs and whether entrypoints were force planned/applied via GUARDIAN_DIRS. If a PR in the history (and not in the feature branch history) was force applied this way then we should force the author to rebase too.
### Detailed design
We will need to update [tagrep](https://github.com/abcxyz/tagrep) to fetch the history of all PRs in the git log that are not in the feature branch.
One possible solution is to make tagrep be able to handle an array of target PRs (by commit hash in this case) and introduce a strategy for merging the results from these PRs. In this case we just want a concatenated list of the unique GUARDIAN_DIRS from all PRs in the list.
### Alternatives considered
1. Ignore it. Its a low risk
2. Don't use PR descriptions to trigger plan/applys. Force users to edit files
Guía de contribución
Línea de trabajo
The issue requires modifying the tagrep tool to process an array of target PRs from git history and merge their GUARDIAN_DIRS entries. Start by examining the tagrep repository to understand its current interface and data structures. Look at how guardian currently calls tagrep for merge-checks. Determine how to fetch the git log for PRs not in the feature branch and design a strategy to concatenate unique GUARDIAN_DIRS. Testing will involve simulating PR histories with force-applied entries.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Área
- devops, tooling
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100