Créer une Pull Request

Créer une PR GitHub pour la branche actuelle, faire transitionner les tickets Jira liés vers le statut review, et enregistrer l'URL de la PR sur ces tickets.

Préconditions

• Au moins un commit ajoute des tests. Quand aucun ne le fait, demander à l'utilisateur une justification et refuser de procéder sans une. Les seules exceptions sont les PRs sans changement de code (par exemple, mises à jour de clés de langue ou changements markdown).

• La branche actuelle est une branche de développement, pas master ou toute autre branche protégée.

• La skill pr-check doit réussir. Ignorer uniquement quand ${ARGUMENTS} contient --skip-pr-check. Un ignoration nécessite une raison : la prendre du texte suivant le flag si présent, sinon demander la raison à l'utilisateur. La raison est enregistrée dans la section PR Check, qui est écrite pour un ignoration plutôt que omise.

Entrée

Branch

La branche Git actuelle doit contenir les commits prêts à être livrés.

Tickets Jira

Une branche peut couvrir plus d'un ticket. Résoudre l'ensemble de tickets — chaque ticket que la PR touche.

La clé du ticket suit le modèle LPD-12345, LCD-12345, LRCI-1234, et formes similaires (lettres majuscules, tiret, chiffres).

Collecter chaque clé de ticket distincte depuis les sujets des commits de la branche par rapport à master. Chaque sujet est préfixé par son ticket (LPD-12345 <subject>); extraire chaque clé distincte, dans l'ordre des commits (plus ancien en premier). Quand aucun commit porte un ticket, demander à l'utilisateur d'en fournir un.

Référentiel cible

Le référentiel cible par défaut est <fork-owner>/liferay-portal. Quand ${ARGUMENTS} nomme un org/repo différent, l'utiliser; quand cela correspond à un alias ci-dessous, développer l'alias; sinon, demander à l'utilisateur de choisir <fork-owner> parmi l'un des forks d'équipe :

• liferay-ac
• liferay-appsec
• liferay-bpm
• liferay-commerce
• liferay-content-management
• liferay-core-infra
• liferay-database-infra
• liferay-devtools
• liferay-frontend
• liferay-headless
• liferay-page-management
• liferay-platform-experience
• liferay-search
• liferay-site-management

Les alias courts suivants se résolvent en un référentiel cible :

• brian → brianchandotcom/liferay-portal

Le head de la PR est <github-username>:<branch-name> (le nom d'utilisateur GitHub est lu depuis l'URL du remote origin de l'utilisateur — par exemple, git@github.com:brianchandotcom/liferay-portal.git donne brianchandotcom), et la base est master.

Résultat attendu

Branche poussée

Pousser la branche actuelle vers le remote de l'utilisateur quand elle n'a pas été poussée encore ou quand de nouveaux commits locaux existent.

Pull Request

Le titre est concis (moins de 72 caractères) et préfixé par la clé du premier ticket de l'ensemble :

LPD-83847 Fix OutOfMemoryError during batch engine import

Le corps suit ce format, avec un lien browse par ticket de l'ensemble :

https://liferay.atlassian.net/browse/TICKET-ID-1
https://liferay.atlassian.net/browse/TICKET-ID-2

## What Is Being Fixed

Explain the problem or bug that motivated the change — what was going wrong or what was missing.

## How It Is Being Fixed

Explain the approach taken across all commits. Describe the key changes and the reasoning behind the approach. Write in plain prose rather than bullet points.

## Why Are There No Tests?

This optional section is only included when the commits do not add any tests. It should contain the rationale provided by the user.

## PR Check

<pr-check Results Summary>

<!-- pr-check {"result": "<state>", "sha": "<tested-SHA>"} -->

La section PR Check est le bloc Results Summary émis par la skill pr-check exécutée comme précondition — la ligne d'état global, le SHA testé, et le tableau par validation, collés textuellement — suivi d'un marqueur caché. Le marqueur est un commentaire HTML, invisible en Markdown rendu, dont la charge utile est un objet JSON de la forme <!-- pr-check {"result": "<state>", "sha": "<tested-SHA>"} -->, où <state> est success quand l'état global est PASS et failure quand il est FAIL, et <tested-SHA> est le SHA complet de 40 caractères du bloc Results Summary. Le webhook lit les champs result et sha pour appliquer le statut de commit pr-check à ce SHA et le label pr-check - <state> à la PR, donc cette skill n'enregistre elle-même aucun statut ou label.

Quand pr-check a été ignoré via --skip-pr-check, écrire toujours la section, mais comme une ignoration plutôt qu'une exécution. Sous le même titre ## PR Check, le corps est une seule ligne **pr-check: SKIPPED** — <reason> sans tableau, et la charge utile du marqueur ajoute un champ reason aux côtés de result (défini à skipped) et du SHA du head de la PR. Les clés de l'objet JSON sont alphabétiques (reason, result, sha).

**pr-check: SKIPPED** — <reason>

<!-- pr-check {"reason": "<reason>", "result": "skipped", "sha": "<head-SHA>"} -->

Le webhook applique le statut et le label quand il traite l'événement pull_request pour la PR nouvellement ouverte, donc aucune étape publish n'est nécessaire à la création. Utiliser la skill pr-check-publish uniquement pour enregistrer une exécution pr-check ultérieure sur une PR existante.

Utiliser un style direct, au point. Éviter d'être verbeux. Présenter le titre et le corps proposés à l'utilisateur avant de soumettre, et procéder une fois qu'ils approuvent.

Créer la pull request avec --body-file, ou avec --body à partir d'une variable heredoc entre guillemets; l'un ou l'autre garde le ! littéral du marqueur hors de la ligne de commande, où il pourrait autrement déclencher l'expansion historique et corrompre le marqueur. Utiliser mktemp pour le fichier pour le tenir hors de l'arborescence de travail, et le supprimer après.

body_file=$(mktemp)

gh pr create \
    --base master \
    --body-file "${body_file}" \
    --head <github-username>:<branch-name> \
    --repo <target-org/repo> \
    --title "<title>"

rm "${body_file}"

Tickets Jira transitionés

Appliquer les étapes ci-dessous à chaque ticket de l'ensemble de tickets, enregistrant le résultat par ticket et continuant en cas d'échec.

Pour chaque ticket, le récupérer (type de ticket, statut, sous-tâches) et résoudre le ticket cible — celui dont le statut reflète le travail actif et sur lequel l'URL de la PR est enregistrée :

Quand la cible n'est pas déjà dans un statut en cours, la transitionner d'abord :

Ensuite la transitionner vers review :

Quand la transition review échoue (par exemple, parce que le ticket est déjà dans un statut ultérieur), continuer quand même pour enregistrer l'URL de la PR.

Définir le champ Git Pull Request (customfield_10201) sur le ticket cible à la nouvelle URL de PR.

Pull Request existante

Ce traitement s'applique par ticket cible, tout en enregistrant l'URL de la PR ci-dessus.

Quand le champ Git Pull Request contient déjà une ou plusieurs URLs de PR, demander à l'utilisateur si la nouvelle PR remplace la précédente ou est ajoutée à côté d'elle.

Quand l'utilisateur choisit remplace :

1. Écraser Git Pull Request avec la nouvelle URL de PR, supprimant la valeur précédente.

2. Ajouter un commentaire sur la PR précédente, créant un lien vers la nouvelle (par exemple, Superseded by <new-pr-url>.).

3. Fermer la PR précédente si possible. Quand l'utilisateur n'a pas la permission de la fermer directement, ajouter un commentaire ci:close à la place, pour que le bot CI la ferme.

Quand l'utilisateur choisit ajoutée :

1. Ajouter la nouvelle URL de PR à la valeur existante, séparant chaque URL par une virgule et un espace.

Résumé

Rapporter à l'utilisateur :

• Chaque ticket de l'ensemble, avec son statut résultant et son lien.
• L'URL de la PR.