Créer une build Konflux manuelle à partir d'une PR

Étant donné une PR et un nom de composant, créez un PipelineRun manuel qui produit une image conteneur. Par défaut, l'image expire après 30 jours. Utilisez --non-expiring pour produire une image permanente.

Exemples d'utilisation

1. Build d'un composant spécifique à partir d'un numéro de PR (expire dans 30 jours) : /konflux-build 7813 hypershift-release-mce-26

2. Build à partir d'une URL de PR (demandera le composant) : /konflux-build https://github.com/openshift/hypershift/pull/7813

3. Build d'une image non-expirante pour un hotfix : /konflux-build 7813 hypershift-operator --non-expiring

4. Build utilisant un modèle de pipeline spécifique : /konflux-build 7813 .tekton/hypershift-release-mce-26-push.yaml

5. Build de l'opérateur principal à partir d'une PR : /konflux-build 7500 hypershift-operator

Ce que cette commande fait

1. Vérifie que vous êtes connecté au cluster Konflux (stone-prd-rh01)
2. Résout la PR pour obtenir le SHA du commit HEAD et la branche de base
3. Trouve le modèle de pipeline push correspondant dans .tekton/ sur la branche de base
4. Génère un YAML PipelineRun manuel avec les variables de modèle résolues
5. Définit l'expiration de l'image à 30 jours (ou la supprime si --non-expiring est spécifié)
6. Crée le PipelineRun et attend sa complétion
7. Signale la référence finale de l'image avec le digest @sha256:

Entrée

• PR : $ARGUMENTS (URL GitHub de PR ou numéro pour openshift/hypershift)
• Composant ou fichier de pipeline : soit un nom de composant (ex. hypershift-operator), soit un chemin vers un modèle de pipeline spécifique (ex. .tekton/hypershift-release-mce-26-push.yaml). Si non spécifié, demandez à l'utilisateur quel composant builder.
• Si --non-expiring est présent dans les arguments, produisez une image permanente ; sinon, définissez image-expires-after: 30d

Étapes

0. Pré-vérification : vérifier la connexion OpenShift

Avant toute autre chose, vérifiez que l'utilisateur est connecté au bon cluster et au bon projet :

1. Exécutez oc whoami --show-server et confirmez qu'il retourne https://api.stone-prd-rh01.pg1f.p1.openshiftapps.com:6443. Si ce n'est pas le cas, arrêtez et dites à l'utilisateur de se connecter :

   oc login https://api.stone-prd-rh01.pg1f.p1.openshiftapps.com:6443

2. Exécutez oc project -q et confirmez qu'il retourne crt-redhat-acm-tenant. Si ce n'est pas le cas, changez vers ce projet :

   oc project crt-redhat-acm-tenant

   Si le changement échoue, arrêtez et dites à l'utilisateur qu'il n'a pas accès à l'espace de noms requis.

Procédez aux étapes suivantes uniquement après que ces deux vérifications réussissent.

1. Résoudre la PR

Utilisez gh pr view <PR> --json headRefOid,headRefName,baseRefName,url pour obtenir :

• Le SHA du commit (headRefOid)
• La branche de base (baseRefName) — cela détermine quel modèle push utiliser
• L'URL de la PR pour référence

2. Trouver le modèle de pipeline push

Si l'utilisateur a fourni un chemin de fichier de pipeline spécifique (ex. .tekton/hypershift-release-mce-26-push.yaml), utilisez directement ce modèle via git show <baseRef>:<pipeline-file>.

Sinon, cherchez dans le répertoire .tekton/ de la branche de base de la PR les fichiers *-push.yaml. Faites correspondre par nom de composant si fourni, ou listez les composants disponibles et laissez l'utilisateur choisir.

Le modèle se trouve sur la branche de base de la PR. Utilisez git show <baseRef>:.tekton/ pour lister les modèles disponibles, puis git show <baseRef>:.tekton/<template-file> pour lire le modèle choisi.

3. Générer le YAML PipelineRun

Prenez le modèle de pipeline push et résolvez-le en un PipelineRun concret :

• Remplacez name par generateName basé sur le champ name du modèle, en remplaçant -on-push par -manual-push-
• Supprimez toutes les annotations pipelinesascode.tekton.dev/* (ce sont des annotations de déclenchement PaC, non nécessaires pour les exécutions manuelles)
• Remplacez {{revision}} et {{source_url}} par les valeurs réelles :
  • {{revision}} → le SHA du commit HEAD de la PR
  • {{source_url}} → https://github.com/openshift/hypershift.git
  • {{target_branch}} → la branche de base de la PR
• Gestion de l'expiration de l'image :
  • Si --non-expiring a été spécifié : supprimez entièrement le paramètre image-expires-after
  • Sinon : assurez-vous qu'un paramètre image-expires-after est présent avec la valeur 30d (ajoutez-le si le modèle n'en a pas, ou mettez-le à jour s'il en a un)
• Remplacez la référence au secret workspace git-auth ({{ git_auth_secret }}) par git-auth-empty
• Si pipelineRef utilise un resolver: git, gardez-le tel quel. S'il utilise name:, gardez-le tel quel.
• Écrivez le YAML dans /tmp/<component>-manual-push.yaml

4. Assurer que le secret git-auth-empty existe

La tâche Tekton git-clone nécessite que l'espace de travail git-auth soit un secret de type kubernetes.io/basic-auth. Puisque openshift/hypershift est un dépôt public, nous utilisons un secret vide au lieu de vraies credentials (qui seraient visibles à tous les utilisateurs du tenant) :

oc get secret git-auth-empty -n crt-redhat-acm-tenant 2>/dev/null || \
oc create secret generic git-auth-empty \
  --type=kubernetes.io/basic-auth \
  --from-literal=username='' \
  --from-literal=password='' \
  -n crt-redhat-acm-tenant

5. Afficher le YAML PipelineRun à l'utilisateur et confirmer

Affichez le YAML généré et demandez la confirmation avant d'appliquer. Indiquez clairement si l'image expire (et quand) ou est permanente.

6. Appliquer le PipelineRun

oc create -f /tmp/<component>-manual-push.yaml

Signalez le nom du PipelineRun.

7. Attendre l'image et signaler le digest

Scrutez oc get pipelinerun <name> toutes les 30 secondes jusqu'à la complétion ou la disparition (archivage).

Une fois terminé (ou si le PipelineRun est archivé avant que nous puissions vérifier), utilisez skopeo pour obtenir le digest de l'image :

skopeo inspect --no-tags docker://<output-image-url>

Signalez la référence finale de l'image sous la forme du digest @sha256:, ex. :

quay.io/redhat-user-workloads/crt-redhat-acm-tenant/<component>@sha256:<digest>

Affichez aussi les digests par architecture à partir de la liste des manifestes s'il s'agit d'une build multi-arch.

Rappelez à l'utilisateur si l'image expire (et quand) ou est permanente.

Gestion des erreurs

Exigences

• CLI oc connecté au cluster Konflux
• CLI gh authentifiée avec accès à openshift/hypershift
• skopeo pour l'inspection d'image
• Accès à l'espace de noms crt-redhat-acm-tenant