Eventi webhook Bitbucket

È possibile utilizzare gruppi di filtri di webhook per specificare quali eventi webhook Bitbucket attivano una compilazione. Ad esempio, puoi specificare che una build venga attivata solo per le modifiche a rami specifici.

È possibile creare uno o più gruppi di filtri di webhook per specificare quali eventi webhook attivano una compilazione. Una build viene attivata se un gruppo di filtri restituisce true, il che si verifica quando tutti i filtri del gruppo restituiscono true. Al momento della creazione di un gruppo di filtri sarà necessario indicare:

Un evento

Per Bitbucket, puoi scegliere uno o più dei seguenti eventi:

• PUSH

• PULL_REQUEST_CREATED

• PULL_REQUEST_UPDATED

• PULL_REQUEST_MERGED

• PULL_REQUEST_CLOSED

Il tipo di evento del webhook è nell'intestazione del campo X-Event-Key. La tabella seguente mostra il modo in cui i valori dell'intestazione X-Event-Key sono mappati ai tipi di eventi.

Nota

È necessario abilitare l'evento merged evento nell'impostazione del webhook Bitbucket se viene creato un gruppo di filtri di webkhook che utilizza il tipo di evento PULL_REQUEST_MERGED. È inoltre necessario abilitare l'declinedevento nelle impostazioni del webhook di Bitbucket se si crea un gruppo di filtri webhook che utilizza il tipo di evento. PULL_REQUEST_CLOSED

Valore intestazione X-Event-Key	Tipo di evento
repo:push	PUSH
pullrequest:created	PULL_REQUEST_CREATED
pullrequest:updated	PULL_REQUEST_UPDATED
pullrequest:fulfilled	PULL_REQUEST_MERGED
pullrequest:rejected	PULL_REQUEST_CLOSED

InfattiPULL_REQUEST_MERGED, se una pull request viene unita alla strategia squash e il ramo pull request viene chiuso, il commit originale della pull request non esiste più. In questo caso, la variabile di CODEBUILD_WEBHOOK_MERGE_COMMIT ambiente contiene l'identificatore dello squashed merge commit.

Uno o più filtri opzionali

Per specificare un filtro, utilizza un'espressione regolare. Affinché un evento attivi una build, ogni filtro all'interno del gruppo ad esso associato deve restituire true.

ACTOR_ACCOUNT_ID(ACTOR_IDnella console)

Un evento webhook attiva una build quando l'ID di un account Bitbucket corrisponde al modello di espressione regolare. Questo valore è presente nella proprietà account_id dell'oggetto actor nel payload del filtro webhook.

HEAD_REF

Un evento webhook attiva una build quando il riferimento alla testina corrisponde al modello di espressione regolare (ad esempio, and). refs/heads/branch-name refs/tags/tag-name Un filtro HEAD_REF valuta il nome di riferimento Git per il ramo o il tag. Il nome del ramo o del tag è presente nel campo name dell'oggetto new nell'oggetto push del payload del webhook. Per gli eventi di richiesta pull, il nome del ramo è presente nel campo name dell'oggetto branch dell'oggetto source nel payload del webhook.

BASE_REF

Un evento webhook attiva una build quando il riferimento di base corrisponde al modello di espressione regolare. Un filtro BASE_REF funziona solo con gli eventi di richiesta pull (ad esempio, refs/heads/branch-name). Un filtro BASE_REF valuta il nome di riferimento Git per il ramo. Il nome del ramo è presente nel campo name dell'oggetto branch nell'oggetto destination nel payload del webhook.

FILE_PATH

Un webhook attiva una build quando il percorso di un file modificato corrisponde al modello di espressione regolare.

COMMIT_MESSAGE

Un webhook attiva una build quando il messaggio di head commit corrisponde al modello di espressione regolare.

WORKFLOW_NAME

Un webhook attiva una build quando il nome del flusso di lavoro corrisponde al modello di espressione regolare.

Nota

Puoi trovare il payload del webhook nelle impostazioni del webhook del tuo repository Bitbucket.

Argomenti

• Filtro di eventi webhook Bitbucket (console)
• Filtro di eventi webhook Bitbucket (SDK)
• Filtro di eventi webhook Bitbucket (AWS CloudFormation)