View a markdown version of this page

Approvazione dei commenti della pull request - AWS CodeBuild
Come funzionaConfigurazioneEsempiAWS CloudFormationConfigurazione della console

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Approvazione dei commenti della pull request

CodeBuild supporta le politiche di compilazione delle richieste pull che forniscono un controllo aggiuntivo sulle build attivate dalle richieste pull. Potresti non voler creare automaticamente richieste pull da utenti sconosciuti fino a quando le loro modifiche non saranno esaminate. Questa funzionalità consente di richiedere a uno dei membri del team di rivedere prima il codice e quindi di eseguire la pipeline. Questa è comunemente usata come misura di sicurezza quando si crea un codice inviato da contributori sconosciuti.

Le politiche di compilazione delle pull request consentono di controllare quando vengono CodeBuild attivate le build per le richieste pull in base alle autorizzazioni e allo stato di approvazione del collaboratore. Ciò è particolarmente importante per gli archivi pubblici o gli archivi che accettano contributi da collaboratori esterni.

Se abilitata, questa funzionalità garantisce che le build vengano attivate per le richieste pull solo quando:

  • La pull request viene creata da un collaboratore fidato.

  • Un collaboratore attendibile approva la pull request pubblicando un commento specifico.

Come funziona

Collaboratori affidabili

Un collaboratore attendibile è un utente il cui ruolo attuale nel sistema di controllo del codice sorgente è impostato nella politica basata sulle pull request come ruolo di approvatore. Quando un collaboratore attendibile crea una pull request, CodeBuild attiva la compilazione automaticamente, mantenendo il comportamento corrente.

Collaboratori non affidabili

Il collaboratore non attendibile è un utente il cui ruolo non è impostato nell'elenco dei ruoli di approvatore. Quando un collaboratore non attendibile crea una pull request:

  1. CodeBuild contrassegna lo stato della compilazione come «Non riuscita» con il messaggio «Approvazione della richiesta di pull required for start a build».

  2. Un collaboratore affidabile deve rivedere le modifiche e pubblicare un commento /codebuild_run(<SHA_OF_THE_LATEST_COMMIT>) per attivare la build. Ad esempio, /codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369).

  3. CodeBuild convalida le autorizzazioni del commentatore e attiva la build se approvata.

  4. I risultati della build vengono riportati nella pagina della pull request.

Sintassi di approvazione dei commenti

I contributori attendibili possono approvare le build utilizzando i seguenti formati di commento:

  • /codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)- I trigger si basano sul commit SHA specificato.

Configurazione

Comportamento predefinito

La policy di compilazione della pull request è abilitata di default per tutti i progetti appena creati CodeBuild .

Parametri dell'API

La politica di compilazione della richiesta pull viene configurata utilizzando il PullRequestBuildPolicy parametro nelle seguenti azioni:

  • CreateWebhook

  • UpdateWebhook

PullRequestBuildPolicystruttura
{
    "requiresCommentApproval": "string",
    "approverRoles": ["string", ...]
}
requiresCommentApproval

Specifica quando è richiesta l'approvazione basata sui commenti prima di attivare una build sulle richieste pull. Questa impostazione determina se le build vengono eseguite automaticamente o richiedono un'approvazione esplicita tramite commenti.

Tipo: stringa

Valori validi:

  • DISABLED- Le build si attivano automaticamente senza richiedere l'approvazione dei commenti.

  • FORK_PULL_REQUESTS- Solo le richieste pull provenienti da repository biforcati richiedono l'approvazione dei commenti (a meno che il contributore non sia uno dei ruoli di approvazione).

  • ALL_PULL_REQUESTS- Tutte le pull request richiedono l'approvazione dei commenti prima dell'esecuzione delle build (a meno che il contributore non sia uno dei ruoli di approvatore). Si tratta del valore di default.

approverRoles

Elenco dei ruoli del repository che dispongono dei privilegi di approvazione per le build di pull request quando è richiesta l'approvazione dei commenti. Solo gli utenti con questi ruoli possono fornire approvazioni valide per i commenti. Se un collaboratore della pull request rientra in uno di questi ruoli, le relative build di pull request si attiveranno automaticamente.

Tipo: array di stringhe

Valori validi per i GitHub progetti (i valori sono mappati ai ruoli): GitHub

  • GITHUB_ADMIN- Amministratori del repository

  • GITHUB_MAINTAIN- Manutentori del repository

  • GITHUB_WRITE- Utente con autorizzazioni di scrittura

  • GITHUB_TRIAGE- Utente con autorizzazioni di triage

  • GITHUB_READ- Utente con autorizzazioni di lettura

  • Impostazione predefinita: ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]

Valori validi per i GitLab progetti (i valori sono mappati ai GitLab ruoli):

  • GITLAB_OWNER- Proprietario del repository

  • GITLAB_MAINTAINER- Manutentore del repository

  • GITLAB_DEVELOPER- Utente con autorizzazioni di sviluppatore

  • GITLAB_REPORTER- Utente con autorizzazioni di reporter

  • GITLAB_PLANNER- Utente con autorizzazioni di pianificazione

  • GITLAB_GUEST - Utente con autorizzazioni per gli ospiti

  • Impostazione predefinita: ["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]

Valori validi per i progetti Bitbucket (i valori sono mappati ai ruoli di Bitbucket):

  • BITBUCKET_ADMIN - Amministratore del repository

  • BITBUCKET_WRITE- Utente con autorizzazioni di scrittura

  • BITBUCKET_READ - Utente con autorizzazioni di lettura

  • Impostazione predefinita: ["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]

Ruoli GitHub aziendali personalizzati

CodeBuild associa i ruoli del repository GitHub Enterprise (GHE) personalizzati a GITHUB_* valori standard in base al livello di autorizzazione più elevato concesso al ruolo personalizzato. CodeBuild valuta le autorizzazioni dal privilegio più alto a quello più basso e la prima autorizzazione abilitata determina il ruolo mappato.

  • admin → GITHUB_ADMIN

  • maintain → GITHUB_MAINTAIN

  • push(scrivere) → GITHUB_WRITE

  • triage → GITHUB_TRIAGE

  • pull(leggi) → GITHUB_READ

Ad esempio, un ruolo personalizzato a cui vengono assegnati entrambi push i triage permessi GITHUB_WRITE perché push ha privilegi superiori a. triage

Se un ruolo personalizzato non dispone di alcuna delle autorizzazioni riconosciute (admin, maintain, push, triage, pull all disabled), l'utente non corrisponde a nessun ruolo di approvatore e viene considerato un collaboratore non attendibile.

GitHub I ruoli standard (Admin, Maintain, Write, Triage, Read) vengono mappati direttamente ai valori corrispondenti senza una risoluzione basata sulle autorizzazioni. GITHUB_*

Esempi

Abilita l'approvazione dei commenti per tutte le pull request

Per utilizzare l' AWS CodeBuild SDK per abilitare o disabilitare la policy Pull Request Build per un webhook, utilizza il pullRequestBuildPolicy campo nella sintassi della richiesta dei metodi CreateWebhook or UpdateWebhook API. Per ulteriori informazioni, consulta WebhookFilter nella documentazione di riferimento dell’API CodeBuild .

Gli utenti con GitHub i ruoli Admin, Maintain e Write verranno considerati collaboratori affidabili.

"pullRequestBuildPolicy": {
    "requiresCommentApproval": "ALL_PULL_REQUESTS",
    "approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
Abilita l'approvazione dei commenti solo per gli amministratori e i manutentori del repository

Gli utenti con GitHub i ruoli Admin e Maintain verranno trattati come collaboratori affidabili.

"pullRequestBuildPolicy": {
    "requiresCommentApproval": "FORK_PULL_REQUESTS",
    "approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN"]
}
Disattiva l'approvazione dei commenti
"pullRequestBuildPolicy": { 
    "requiresCommentApproval": "DISABLED"
}

AWS CloudFormation

Per utilizzare un AWS CloudFormation modello per abilitare o disabilitare la politica Pull Request Build per un webhook, usa la PullRequestBuildPolicy proprietà. La YAML-formatted parte seguente di un AWS CloudFormation modello crea un progetto con un webhook con la Pull Request Build Policy abilitata per tutte le richieste pull. I ruoli di manutenzione e amministratore sono specificati come approvatori.

CodeBuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: MyProject
    ServiceRole: service-role
    Artifacts:
      Type: NO_ARTIFACTS
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:5.0
    Source:
      Type: BITBUCKET
      Location: source-location
    Triggers:
      Webhook: true
      FilterGroups:
        - - Type: EVENT
            Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
          - Type: BASE_REF
            Pattern: ^refs/heads/main$
            ExcludeMatchedPattern: false
      PullRequestBuildPolicy:
        RequiresCommentApproval: ALL_PULL_REQUESTS
        ApproverRoles:
          - GITHUB_MAINTAIN
          - GITHUB_ADMIN

Configurazione della console

Per utilizzare la console AWS di gestione per filtrare gli eventi webhook:

  1. Per l'approvazione dei commenti, seleziona disabilitato o abilitato per tutte le richieste pull (ALL_PULL_REQUEST) o solo per le richieste pull provenienti da forks (FORK_PULL_REQUEST).

  2. Per i ruoli Approvatore, seleziona i ruoli del repository con privilegi di approvazione per le build di pull request quando è richiesta l'approvazione dei commenti.

Per ulteriori informazioni, consulta le pagine Creare un progetto di compilazione (console) e WebhookFilter nella Documentazione di riferimento dell'API CodeBuild .

Console di eventi webhook di origine primaria con approvazione dei commenti.