Una cosa che si fa spesso come project owner/maintainer è la gestione del backlog. Usando GitHub, molte persone si sono dovuti abituare per anni all'idea che le "issue" fossero l'unico modo di gestire sia malfunzionamenti veri e propri, ma anche richieste di nuove funzionalità, mischiando quindi ogni tipologia di richiesta: questo ha portato loro un lavoro aggiuntivo poiché senza filtri, l'unico modo per avere un backlog "ordinato" è sempre stato quello di catalogare le issue tramite le label. Invece, chi arriva da JIRA o Azure DevOps, per citarne alcuni, è sempre stato abituato a lavorare con una gerarchia di elementi che individua fin da subito la differenza tra una epic, una feature, un task o un bug. Ed è proprio per questo motivo che anche GitHub ha recentemente introdotto gli issue types, non tipi predefiniti ma personalizzabili a livello di organization: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization

Se siamo nuovi in un certo progetto e vogliamo scoprire quali sono gli issue type presenti, possiamo lanciare una semplice query:

gh api graphql -f query='
{
  repository(owner: "microsoft", name: "vscode") {
    issueTypes(first: 20) {
      nodes {
        id
        name
        description
      }
    }
  }
}'

Per recuperare l'issue type di una specifica issue, invece, possiamo eseguire una query più specifica che lavora sull'ID:

gh api graphql -f query='
{
  repository(owner: "microsoft", name: "vscode") {
    issue(number: 123456) {
      id
      title
      issueType {
        name
      }
    }
  }
}'

Per creare una issue e associare l'issue type corretto bisogna eseguire più passaggi:

gh graphql -f query='
mutation {
  createIssue(input: {
    repositoryId: "REPO_ID"
    title: "This is my feature request"
    body: "To be defined"
  }) {
    issue {
      id
      number
    }
  }
}'

gh graphql -f query='
mutation {
  updateIssue(input: {
    id: "ISSUE_GRAPHQL_ID"
    issueTypeId: "TASK_ISSUE_TYPE_ID"
  }) {
    issue {
      number
      issueType {
        name
      }
    }
  }
}'

Infatti, prima di tutto siamo andati a creare la issue normalmente all'interno del repository di riferimento e poi la siamo andati ad aggiornare con una mutation dell'oggetto stesso. Da notare come dobbiamo passare i nodeId, quindi, in questo caso, avremo bisogno sia del riferimento alla issue, ottenuto in fase di creazione dell'oggetto stesso, sia del riferimento alla issue type ottenuto con la query effettuata in precedenza sul repository per ottenere gli issue type.