Les presets lancent des commandes de lint, test ou build avec Bun. Le dépôt doit fournir les scripts attendus par le preset choisi.
Type technique : ci_verify. Runtime : docker.
Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
Installe les dépendances avec bun install --frozen-lockfile, puis lance bun run check, bun run test ou bun run build. Utilisez Personnalisé pour un autre script.
workingDir Répertoire de travail (relatif)
Sous-dossier du workspace où exécuter les commandes (ex. apps/backend).
image Image de conteneur (shell)
Image contenant les outils de vos commandes. Par défaut : oven/bun:1 pour Shell et Vérification ; node:22-bookworm pour Release.
secretCredentialIds Secrets
Connexions Secrets injectées comme variables d'environnement du script (process.env, os.environ…). Le fichier qui les porte est effacé dès le démarrage du conteneur.
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
Testez le nœud avec des données représentatives. Contrôlez sa sortie dans l’inspecteur et les logs, puis utilisez le mapping de l’éditeur pour les champs des nœuds suivants. Un test de déclencheur avec payload simulé ne valide pas la livraison du service externe.
Lint, tests ou build (presets bun)
Utilisation et spécificités
Les presets lancent des commandes de lint, test ou build avec Bun. Le dépôt doit fournir les scripts attendus par le preset choisi.
Type technique :
ci_verify. Runtime :docker.Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
presetenum"check"check,test,build,customcommandsarrayworkingDirstringimagestringsecretCredentialIdsarray[]secretFilesarray[]secretFiles[].pathstringsecretFiles[].contentstringworkspaceSourceunion{"kind":"upstream"}workspaceSource.kindliteral"upstream"upstream,nodeworkspaceSource.keystringexecutionTargetunion{"kind":"host"}executionTarget.kindliteral"host"host,remote_server,kube,swarmexecutionTarget.serverIdstringexecutionTarget.providerenumaws,gcp,scaleway,ovh,azure,digitalocean,hetznerexecutionTarget.clusterIdstringexecutionTarget.namespacestringAide de configuration
commandsCommandes
presetPreset
workingDirRépertoire de travail (relatif)
imageImage de conteneur (shell)
secretCredentialIdsSecrets
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
{ "preset": "check", "workspaceSource": { "kind": "upstream" }, "executionTarget": { "kind": "host" } }Vérification
Testez le nœud avec des données représentatives. Contrôlez sa sortie dans l’inspecteur et les logs, puis utilisez le mapping de l’éditeur pour les champs des nœuds suivants. Un test de déclencheur avec payload simulé ne valide pas la livraison du service externe.
Voir aussi : Expressions et données, Exécutions, Catalogue des nœuds.