Applicare un filtro per recuperare alcune issue di GitHub

di Matteo Tumiati, in DevOps,

Quando si gestiscono repository di grandi dimensioni, è piuttosto normale avere anche un backlog con un numero smisurato di issue. Questo non succede solamente nel caso dei repository di organization, ma anche nel mondo open-source, dove chiunque può aprire una issue. Grazie all'introduzione degli "issue template" in GitHub, abbiamo la possibilità di creare dei work item che siano più o meno tutti strutturati allo stesso modo. Al crescere delle issue, però, diventa fondamentale capire se esistono duplicati o issue similari tra di loro, per chiuderli e non farli accumulare inutilmente.

A questo scopo GitHub, tramite la CLI, ci permette di fare un discovery delle issue con il comando gh issue list e possiamo poi andarle a filtrare secondo i nostri criteri:

$items = gh issue list --state open --jq ".[] | select(.title | startswith(\""my title\""))" --json number,title --repo <org>/<repo> -L 1000 | ConvertFrom-Json

foreach ($item in $items) {
  Write-Host "Issue $($item.number) with title: $($item.title)"
}

In questo caso abbiamo utilizzato JQ, integrato nella CLI, per poter filtrare già lato server (ovvero in GitHub) tutti i work item che includono un titolo predefinito, in questo caso che inizia per "my title". A quel punto abbiamo recuperato solo le property che ci interessava effettivamente analizzare, come il numero del work item e il suo titolo per intero. Nell'esempio abbiamo anche un limite di 1000 issue recuperate, ma è facile integrare la paginazione.

Una volta recuperate e fatto il parsing come JSON sfruttando PowerShell, possiamo fare una query su queste ed effettuare le operazioni che più ci interessano. Se sono effettivamente duplicati possiamo, per esempio, chiuderli automaticamente:

foreach ($item in $items) {
  gh issue close $item.number --repo <org>/<repo>
}

Attenzione però: c'è un limite sul numero di chiamate che possono essere fatte tramite le REST API o la CLI, perché di fatto si usa sempre un API token dietro le quinte, pertanto se il numero di issue da chiudere diventa elevato, conviene mettere una sleep tra una operazione e l'altra, oppure cercare di fare una esecuzione a batch.

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

I più letti di oggi