Informations de référence sur les variables de déclenchement

Le système recherche les noms de variable suivants. Lorsqu'un environnement d'étape contient une de ces variables (spécifiquement ou héritée d'un projet ou d'un serveur), des actions sont effectuées.

Variable

Contenu

_CI_BUILD_DELETE

Définissez cette variable sur une valeur quelconque pour supprimer cette génération et les données de génération associées après l'exécution du travail. (La variable de balise est réinitialisée sur sa valeur initiale, avant la génération supprimée, si aucune autre génération de projet n'est exécutée.)

_CI_BUILD_KEEP

Définissez cette variable sur une valeur quelconque pour conserver la génération et les données de génération associées après l'exécution du travail. Par exemple, si votre travail inclut un lien d'adaptateur et que l'étape d'adaptateur échoue, les autres étapes du projet ne sont pas exécutées. Vous souhaiterez peut-être conserver une copie des enregistrements de génération pour le travail à des fins de débogage, par exemple.

CLEARCASE_VIEW

Démarre la vue ClearCase spécifiée. La vue spécifiée dans cette variable doit exister, et l'étape utilisant cette variable doit être définie sur "absolue". Sur des systèmes exécutant Microsoft Windows, cette variable doit être utilisée avec l'option de configuration cc_suppress_server_root pour l'agent dans bfagent.conf.

_CLEARCASE_VIEWS

Spécifie une liste de vues ClearCase à démarrer avant l'exécution de la commande. Définissez la valeur sur une liste de vues séparée par une virgule ; par exemple, "Vue1,Vue2,Vue3".

_CLEARCASE_VOBS

Indique une liste de VOB ClearCase à installer avant l'exécution de la commande. Définissez la valeur sur une liste de VOB séparée par des virgules ; par exemple, "\Vob1,\Vob2,\Vob3".

_CONTEXT_LOG_RANGE

Utilisez cette variable pour limiter les sorties du journal aux lignes proches des correspondances de filtre. Elle accepte une valeur d'entier positif, et conduit le système à omettre la sortie de journal, sauf pour une série de lignes autour de chaque occurrence de chaîne de filtrage dont la taille est égale à la valeur de la variable. Si vous définissez, par exemple, la variable sur 5, vos journaux affichent uniquement les lignes avec des correspondances de filtre ainsi que les 5 lignes précédentes et les 5 lignes suivantes.

_ERROR_THRESHOLD

Etablit le nombre maximal d'erreurs (trouvées par les filtres Déf. échec que vous avez définis) autorisées. A l'aide de cette variable, vous pouvez établir des seuils d'échec et de message pour des étapes individuelles ou pour un projet.

Utilisez l'un des formulaires suivants :

  • Une valeur de 5 ou F5 indique que le travail doit échouer si plus de 5 erreurs se produisent.
  • Une valeur de N7 indique que le système doit ajouter un message aux notes du travail si plus de 7 erreurs se produisent. Le message indique que ce seuil a été atteint.

Lorsque vous utilisez la variable dans une étape, le système compte les erreurs dans l'étape individuelle. Des formes supplémentaires sont disponibles :

  • Une valeur comme W9 indique qu'après 9 erreurs, l'étape est mise à l'état d'avertissement, quelque soit les erreurs ultérieures trouvées par les filtres.
  • Une valeur comme C8 indique qu'après 8 erreurs, l'étape est mise à l'état d'échec ; toutefois, n'importe quel filtre Effacer l'échec peut effacer l'échec.

REMARQUE : les erreurs comptabilisées dans cette variable sont définies en tant que chaînes correspondant à des filtres avec les actions Déf. échec et qui sont affectées aux étapes du projet. Chaque chaîne identifiée comme échec par un filtre compte comme une erreur pour le nombre total de l'étape et pour le nombre total du projet.

_EXITCODE_MAP

Indique une liste de nombres (séparés par des virgules, des espaces, des points-virgules ou des doubles points) que le système doit accepter comme indicateurs de réussite d'une étape. Par défaut, un code de sortie de 0 indique la réussite ; lorsque cette variable est spécifiée, n'importe quelle valeur qui y est répertoriée indique également la réussite.

_InterfaceLoggingLevel

Contrôle la quantité de données de journal consignée par Build Forge lorsqu'il exécute une étape d'adaptateur. Créez une variable d'environnement (dans votre environnement d'adaptateur) portant le nom _InterfaceLoggingLevel. Attribuez-lui une valeur d'entier de 0 à 8. Les niveaux de connexion sont inclusifs, le niveau 2, par exemple, inclut les informations des niveaux 1 et 0.
  • 0 : Ligne Exec + erreurs de connexion au serveur ou annulation de la notification
  • 1 : Commandes analysées (telles qu'elles seront envoyées au serveur)
  • 2 : Commandes non analysées (avant que leurs variables locales aient été définies)
  • 3 : Lignes de transaction SET de générations et de variable d'environnement
  • 4 : Lignes de transaction SET de variables internes et temporaires
  • 5 : Evaluations d'environnement, ajouts de groupes de courrier électronique, lignes de consignation du texte de nomenclature
  • 6 : Lignes de démarrage/fin de bloc & sous-bloc
  • 7 : (Niveau de consignation par défaut) Résultats d'agent qui seront vérifiés selon des modèles de pattern, plus les lignes qui correspondent aux patterns.
  • 8 : Tous les résultats d'agent

_LOG

Spécifie un nom de chemin permettant de créer un fichier journal contenant la sortie de ligne de l'agent Build Forge.

Remarque : Ce journal ne contient pas d'horodatages tant que _LOG_TIMESTAMP n'est pas également spécifié. Les données du journal de ce fichier sont généralement formatées de la manière suivante : code agent, intervalle journal et message.

Utilisez cette variable pour sauvegarder une copie du journal du travail sur le serveur. Si le fichier existe, le système y fait un ajout.

_LOG_TIMESTAMP

Préfixe chaque ligne de sortie _LOG par un horodatage. La valeur de cette variable doit être une chaîne de format dans la même syntaxe strftime que celle utilisée par les commandes d'environnement .date et .gmdate.

Remarque : Nécessite _LOG.

_MAP

Voir Mappage d'unités Windows pour une description de l'utilisation de cette variable.

_NO_PREPARSE_COMMAND

Le système essaie de résoudre les valeurs des variables d'environnement avant d'envoyer des commandes aux agents. Lorsque la variable _NO_PREPARSE_COMMAND est définie (avec une valeur quelconque), le système envoie les variables aux agents sans les résoudre. Utilisez cette variable pour vous assurer que l'interpréteur de commandes de votre système d'exploitation gère les variables.

_PRISM_DIR_POSTCMD

Utilisé avec les plug-ins des environnements de développement intégrés. Indique une commande à exécuter sur des répertoires après que l'étape du projet a été exécutée. Voir Variables spéciales pour les projets de test.

_PRISM_DIR_PRECMD

Utilisé avec les plug-ins des environnements de développement intégrés. Indique une commande à exécuter sur des répertoires avant qu'ils soient copiés sur le serveur pour une étape du projet. Voir Variables spéciales pour les projets de test.

_PRISM_FILE_POSTCMD

Utilisé avec les plug-ins des environnements de développement intégrés. Indique une commande à exécuter sur des fichiers après que l'étape du projet a été exécutée. Voir Variables spéciales pour les projets de test.

_PRISM_FILE_PRECMD

Utilisé avec les plug-ins des environnements de développement intégrés. Indique une commande à exécuter sur des fichiers avant qu'ils soient copiés sur le serveur pour une étape du projet. Voir Variables spéciales pour les projets de test.

_SUPPRESS_ENV_OUTPUT

Indique que le système omet les messages d'environnement du journal. Par défaut, cette variable n'est pas définie et toutes les valeurs de variables de l'environnement sont imprimées avant l'exécution de la commande de l'étape. Les valeurs apparaissent sous la forme d'entrées ENV dans le journal d'étape. La variable peut être définie sur les valeurs suivantes :
  • ALWAYS : toujours omettre les messages ENV
  • Toute autre valeur : omettre les messages ENV. Cependant, si la commande échoue, les messages ENV sont imprimés après le message de la commande. Ces informations peuvent être utiles pour le débogage de l'échec d'exécution de la commande.

_SUPPRESS_AGENT_LOG_OUTPUT

Lorsque cette variable est définie sur 1, cela empêche l'agent d'envoyer des données de journal au moteur. A comparer à _SUPPRESS_LOG_OUTPUT, où les données de journal sont envoyées à partir de l'agent mais sont supprimés par le moteur.

Remarque : L'utilisation de cette variable empêche les correspondances de filtre.

_SUPPRESS_LOG_OUTPUT

Lorsque cette variable est définie sur 1, le moteur supprime quasiment toute la sortie de journal reçue depuis l'agent. Certains messages de journal de console ne sont pas supprimés. Les correspondances de filtres sont indiquées.

_TIMEOUT

Une valeur qui remplace la propriété Délai pour une ou toutes les étapes du projet.

_TRAP

Une chaîne à exécuter si l'étape en cours échoue ; la chaîne peut être définie sur le nom d'un fichier ou d'une commande exécutable. REMARQUE : le résultat de la commande n'est pas renvoyé à la console, car la connexion entre la console et l'agent est fermée avant l'échec de l'étape ; si vous souhaitez conserver le résultat d'une commande exécutée via _TRAP, définissez la commande se sorte à ce qu'elle consigne son résultat dans un fichier pour une récupération ultérieure.

_USE_BFCREDS

Lorsque cette variable est définie sur 1, le système utilise les droits d'accès de connexion de l'utilisateur pour se connecter aux serveurs, au lieu des droits d'accès stockées dans l'autorisation de serveur rattachée au serveur. Le système utilise les droits d'accès de connexion de la console de gestion de l'utilisateur ayant démarré le projet pour exécuter les commandes du projet. Vous pouvez définir cette variable pour une seule étape, ou pour un projet entier.
Remarque : Si vous utilisez l'authentification LDAP/Active Directory, le paramètre système Stockage local de l'authentification utilisateur doit être défini sur Oui (sa valeur par défaut) pour que la fonction _USE_BFCREDS fonctionne. Lorsque le paramètre est défini sur Oui, le système met en cache les informations sur l'authentification utilisateur sous forme chiffrée et peut ensuite accéder aux informations d'authentification utilisateur pour les utiliser avec _USE_BFCREDS.
Conseil : Sous Windows, envisagez de définir également la variable _USE_BFCREDS_DOMAIN.

_USE_BFCREDS_DOMAIN (Windows uniquement)

Lorsque 1 est spécifié, le système utilise le domaine de l'utilisateur en plus des identifiants de connexion utilisés par _USE_BFCREDS pour se connecter aux serveurs.

_XSTREAM_PROTOCOL type

Active les transferts directs de fichiers entre les agents.
Important : Les agents de certains systèmes d'exploitation proposent une prise en charge limitée du transfert direct de fichiers. Voir Configuration du transfert direct de fichiers entre les agents.

Le moteur, l'agent d'envoi et l'agent de réception doivent tous prendre en charge les transferts directs de fichiers. Si l'un d'eux ne prend pas en charge les transferts directs de fichiers, alors _XSTREAM_PROTOCOL est ignoré sans avertissement et la méthode normale de transfert de fichier est utilisée.

Les agents de réception doivent pouvoir créer des connexions TCP sur l'hôte de l'agent de réception. Le cas échéant, il faut configurer les pare-feu pour autoriser les connexions.

Le protocole type détermine la méthode de codage de données qui est l'une des suivantes :

AES-CBC
Des algorithmes solides sur le plan cryptographique sont utilisés pour coder les données. Les deux agents doivent être compilés avec OpenSSL et utiliser le protocole SSL pour la communication avec le moteur. La clé de chiffrement est obtenue à partir du moteur.
PRNG
Un générateur de nombres pseudo-aléatoires est utilisé pour obscurcir le contenu du fichier.
PLAIN
Les fichiers sont transférés en l'état sans codage.

Commentaires en retour