Déployer les variables

Les variables deploy suivantes contrôlent les actions lors de la phase de déploiement et peuvent hériter des valeurs de Variables globales et les remplacer. Insérez ces variables dans l’étape deploy du fichier .magento.env.yaml :

stage:
  deploy:
    DEPLOY_VARIABLE_NAME: value

Pour plus d’informations sur la personnalisation du processus de création et de déploiement :

CACHE_CONFIGURATION

Utilisez CACHE_CONFIGURATION pour fusionner ou remplacer les options frontales et principales du cache générées lors du déploiement.

Pour Adobe Commerce sur les infrastructures cloud, ne modifiez pas directement les app/etc/env.php. Le package de ece-tools génère la configuration de déploiement à partir des .magento.env.yaml, des relations de service et des variables de déploiement prises en charge.

Utilisez VALKEY_BACKEND ou REDIS_BACKEND pour sélectionner le cache pris en charge ou l’implémentation L2 pour la version exacte d’Adobe Commerce. Utilisez des CACHE_CONFIGURATION pour personnaliser des options telles que les reprises de connexion, les délais de lecture, les préfixes de cache ou les clés de préchargement.

La combinaison back-end et cache-service prise en charge dépend de la version de Commerce et du niveau de correctif. Redis n’est pas pris en charge pour Adobe Commerce 2.4.9 ou pour les versions de correctif ultérieures à 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 et 2.4.8-p4. Utilisez Valkey pour les versions où la configuration requise le requiert.

Par défaut, le processus de déploiement remplace la configuration de cache correspondante. Pour fusionner les valeurs spécifiées avec la configuration générée, définissez _merge sur true :

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            connect_retries: 3
          remote_backend_options:
            read_timeout: 10

Pour remplacer la configuration existante avec les valeurs spécifiées dans CACHE_CONFIGURATION, définissez _merge sur false.

L’exemple suivant fusionne les affectations de base de données dans une configuration de cache existante. Utilisez ce type de remplacement uniquement lorsque le serveur principal et la version Commerce sélectionnés le prennent en charge. Appliquez les paramètres frontend à symfony_l2 uniquement si la documentation actuelle de Symfony L2 prend explicitement en charge l’option.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            database: 10
        page_cache:
          backend_options:
            database: 11

L’exemple suivant utilise la fonction de préchargement Redis telle que définie dans le Guide de configuration. Utilisez les instructions Valkey correspondantes pour les versions qui utilisent Valkey.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '061_'
          backend_options:
            preload_keys:
              - '061_EAV_ENTITY_TYPES:hash'
              - '061_GLOBAL_PLUGIN_LIST:hash'
              - '061_DB_IS_UP_TO_DATE:hash'
              - '061_SYSTEM_DEFAULT:hash'

Pour utiliser un modèle REDIS_BACKEND personnalisé qui n’est pas dans la liste autorisée, définissez _custom_redis_backend sur true afin que ece-tools applique la validation appropriée :

stage:
  deploy:
    CACHE_CONFIGURATION:
      frontend:
        default:
          _custom_redis_backend: true
          backend: '\CustomRedisModel'

CLEAN_STATIC_FILES

Active ou désactive le nettoyage fichiers de contenu statique généré pendant la phase de build ou de déploiement. Utilisez la valeur par défaut true en développement comme bonne pratique.

Si vous modifiez du contenu statique par le biais d’un processus distinct, définissez la valeur sur false.

stage:
  deploy:
    CLEAN_STATIC_FILES: false

Si vous ne nettoyez pas les fichiers d’affichage statique avant de les déployer, vous risquez de rencontrer des problèmes si vous déployez des mises à jour sur des fichiers existants sans supprimer les versions précédentes. En raison des règles static file fallback, les opérations de secours peuvent afficher le mauvais fichier si le répertoire contient plusieurs versions du même fichier.

CRON_CONSUMERS_RUNNER

Utilisez cette variable d’environnement pour confirmer que les files d’attente de messages sont en cours d’exécution après un déploiement.

L’exemple suivant exécute les consommateurs sélectionnés et lance plusieurs processus pour chacun d’eux :

stage:
  deploy:
    CRON_CONSUMERS_RUNNER:
      cron_run: true
      max_messages: 1000
      consumers:
       example_consumer_1
       example_consumer_2
      multiple_processes:
        example_consumer_1: 4
        example_consumer_2: 3

L’exemple suivant exécute tous les consommateurs :

stage:
  deploy:
    CRON_CONSUMERS_RUNNER:
      cron_run: true
      max_messages: 1000
      consumers: []

Par défaut, le processus de déploiement remplace les paramètres correspondants dans le fichier env.php. Voir Gérer les files d’attente de messages dans le Guide de configuration de Commerce pour Adobe Commerce On-Premise.

CONSUMERS_WAIT_FOR_MAX_MESSAGES

Configurez le traitement consumers messages de la file d’attente des messages en choisissant l’une des options suivantes :

stage:
  deploy:
    CONSUMERS_WAIT_FOR_MAX_MESSAGES: false

CRYPT_KEY

Lorsque vous déplacez la base de données d’un environnement à un autre sans processus d’installation, vous avez besoin des informations cryptographiques correspondantes. Adobe Commerce utilise la valeur de la clé de chiffrement définie dans le Cloud Console comme valeur crypt/key dans le fichier env.php.

DATABASE_CONFIGURATION

Si vous avez défini une base de données dans la propriété relations du fichier .magento.app.yaml, vous pouvez personnaliser vos connexions à la base de données pour le déploiement.

stage:
  deploy:
    DATABASE_CONFIGURATION:
      some_config: 'some_value'

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne de nouvelles valeurs dans une configuration existante :

stage:
  deploy:
    DATABASE_CONFIGURATION:
      some_config: 'some_new_value'
      _merge: true

Vous pouvez également configurer un préfixe de tableau.

L’exemple suivant utilise le préfixe de tableau ece_ avec les paramètres de connexion par défaut au lieu d’utiliser l’option _merge :

stage:
  deploy:
    DATABASE_CONFIGURATION:
      connection:
        default:
          username: user
          host: host
          dbname: magento
          password: password
      table_prefix: 'ece_'

Exemple de sortie :

MariaDB [main]> SHOW TABLES;
+-------------------------------------+
| Tables_in_main                      |
+-------------------------------------+
| ece_admin_passwords                 |
| ece_admin_system_messages           |
| ece_admin_user                      |
| ece_admin_user_session              |
| ece_adminnotification_inbox         |
| ece_amazon_customer                 |
| ece_authorization_rule              |
| ece_cache                           |
| ece_cache_tag                       |
| ece_captcha_log                     |
...

ELASTICSUITE_CONFIGURATION

Conserve les paramètres de service Elastic Suite personnalisés entre les déploiements et les utilise dans la section « system/default/smile_elasticsuite_core_base_settings » de la configuration Elastic Suite principale. Si le package du compositeur de Elastic Suite est installé, il est configuré automatiquement.

stage:
  deploy:
    ELASTICSUITE_CONFIGURATION:
      es_client:
        servers: 'remote-host:9200'
      indices_settings:
        number_of_shards: 1
        number_of_replicas: 0

          indices_settings:
                  number_of_shards: 1
                  number_of_replicas: 2

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne une nouvelle valeur avec la configuration existante :

stage:
  deploy:
    ELASTICSUITE_CONFIGURATION:
      indices_settings:
        number_of_shards: 1
        number_of_replicas: 2
      _merge: true

Limites connues :

ENABLE_GOOGLE_ANALYTICS

Active et désactive Google Analytics lors du déploiement dans les environnements d’évaluation et d’intégration. Par défaut, Google Analytics est défini uniquement sur l’environnement de production. Pour activer Google Analytics dans les environnements d’évaluation et d’intégration, définissez cette valeur sur true.

Ajoutez la variable d’environnement ENABLE_GOOGLE_ANALYTICS à l’étape deploy dans le fichier .magento.env.yaml :

stage:
  deploy:
    ENABLE_GOOGLE_ANALYTICS: true

FORCE_UPDATE_URLS

Lors du déploiement dans des environnements d’évaluation et de production Pro ou Starter, cette variable remplace les URL de base d’Adobe Commerce dans la base de données par les URL de projet spécifiées par la variable MAGENTO_CLOUD_ROUTES . Pour remplacer le comportement par défaut de la variable de déploiement UPDATE_URLS, utilisez ce paramètre.

stage:
  deploy:
    FORCE_UPDATE_URLS: true

LOCK_PROVIDER

Le fournisseur de verrous empêche l’exécution des tâches et des groupes cron en double. Adobe Commerce on Cloud prend en charge les fournisseurs de verrous file et db.

Dans les environnements d’évaluation et de production Pro, MAGENTO_CLOUD_LOCKS_DIR configure le fournisseur de file. Impossible de remplacer ce paramètre. Dans les environnements Pro Integration et Starter, ece-tools définit le fournisseur de db par défaut. Pour optimiser les performances locales et refléter l’architecture de production, définissez le fournisseur sur file dans ces environnements.

stage:
  deploy:
    LOCK_PROVIDER: 'file'

MYSQL_USE_SLAVE_CONNECTION

Adobe Commerce peut lire plusieurs bases de données de manière asynchrone. Définissez cette variable sur true pour utiliser automatiquement une connexion lecture seule à la base de données afin de recevoir le trafic en lecture seule sur un nœud non principal. Cette connexion améliore les performances grâce à l’équilibrage de charge, car un seul nœud gère le trafic en lecture-écriture. Pour supprimer un tableau de connexion en lecture seule existant du fichier env.php, définissez sur false.

stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true

Lorsque la variable MYSQL_USE_SLAVE_CONNECTION est définie sur true, le système définit le paramètre synchronous_replication sur true par défaut dans le fichier env.php dans les environnements d’évaluation et de production Pro. Lorsque la MYSQL_USE_SLAVE_CONNECTION est définie sur false, le paramètre synchronous_replication n’est pas configuré.

QUEUE_CONFIGURATION

Utilisez cette variable d’environnement pour conserver les paramètres personnalisés du service de file d’attente entre les déploiements. Cette variable prend en charge les protocoles AMQP (pour RabbitMQ) et STOMP (pour ActiveMQ Artemis). Par exemple, si vous préférez utiliser un service de file d’attente de messages existant au lieu de vous fier à l’infrastructure cloud pour le créer, utilisez la variable d’environnement QUEUE_CONFIGURATION pour le connecter à votre site :

stage:
  deploy:
    QUEUE_CONFIGURATION:
      amqp:
        host: test.host
        port: 1234
      amqp2:
        host: test.host2
        port: 12345
      mq:
        host: mq.host
        port: 1234

Pour les artéfacts ActiveMQ utilisant le protocole STOMP :

stage:
  deploy:
    QUEUE_CONFIGURATION:
      stomp:
        host: activemq.host
        port: 61616
        user: username
        password: password

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne de nouvelles valeurs dans une configuration existante :

stage:
  deploy:
    QUEUE_CONFIGURATION:
      _merge: true
      amqp:
        host: changed1.host
        port: 5672
      amqp2:
        host: changed2.host2
        port: 12345
      mq:
        host: changedmq.host
        port: 1234

REDIS_BACKEND

Spécifie la configuration du modèle principal pour le cache Redis.

Le cache Redis n’est pas pris en charge pour Adobe Commerce 2.4.9 ou pour les versions de correctif ultérieures à 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 et 2.4.8-p4. Pour ces versions, utilisez Valkey et la configuration VALKEY_BACKEND correspondante. Vérifiez toujours le service de cache pris en charge dans la configuration requise.

Pour les versions prises en charge par Redis, les modèles principaux disponibles sont les suivants :

L’exemple suivant active le serveur principal du cache synchronisé à distance et le cache L2 :

stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

REDIS_USE_SLAVE_CONNECTION

Adobe Commerce peut lire plusieurs instances Redis de manière asynchrone. Définissez cette variable sur true pour utiliser une connexion en lecture seule à un réplica Redis pour le trafic de lecture tandis que l’instance principale gère le trafic de lecture-écriture. Pour supprimer un tableau de connexion en lecture seule existant de env.php, définissez-le sur false.

stage:
  deploy:
    REDIS_USE_SLAVE_CONNECTION: true

Un service Redis doit être configuré dans les fichiers .magento.app.yaml et services.yaml.

ECE-Tools version 2002.0.18 et versions ultérieures utilisent des réglages plus tolérants aux pannes. Si Adobe Commerce ne peut pas lire les données du réplica Redis, il retourne à l’instance Redis principale.

La connexion en lecture seule n’est pas disponible dans l’environnement d’intégration. Si vous utilisez CACHE_CONFIGURATION, fusionnez les modifications dans la configuration générée et vérifiez que la configuration obtenue conserve la connexion de réplica.

VALKEY_BACKEND

VALKEY_BACKEND spécifie le modèle principal pour la configuration du cache Valkey. La valeur par défaut utilise un nom de classe hérité compatible avec Redis ; cela ne signifie pas que le service doit être Redis.

Pour les versions d’Adobe Commerce antérieures à la version 2.4.9 qui prennent en charge Valkey, les modèles principaux incluent :

Adobe Commerce version 2.4.9 et ultérieure prend également en charge symfony_l2, l’implémentation L2 basée sur le cache de Symfony. symfony_l2 est pris en charge avec Valkey uniquement.

Configuration du cache synchronisé à distance

Pour Adobe Commerce 2.4.8, utilisez la configuration suivante lorsque l’implémentation du cache synchronisé à distance est appropriée :

stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

La spécification du serveur principal synchronisé à distance active le cache L2 et ece-tools génère automatiquement la configuration du cache. Voir exemple de fichier de configuration. Pour personnaliser la configuration générée, utilisez CACHE_CONFIGURATION.

Configurer l’implémentation moderne du cache L2 de Symfony

Pour Adobe Commerce version 2.4.9 et ultérieure, utilisez l’implémentation de Symfony L2 :

stage:
  deploy:
    VALKEY_BACKEND: 'symfony_l2'

La spécification de symfony_l2 comme modèle principal Valkey active le cache L2 et génère ece-tools automatiquement la configuration de cache L2 à partir des détails de connexion au service Valkey, y compris les fronts default et stale_cache_enabled. Définissez des CACHE_CONFIGURATION uniquement lorsque vous devez personnaliser les options principales prises en charge, telles que le répertoire du cache local. Voir Implémentation du cache Symfony L2 dans le Guide de configuration d’Adobe Commerce.

VALKEY_USE_SLAVE_CONNECTION

Adobe Commerce peut lire plusieurs instances Valkey de manière asynchrone. Définissez VALKEY_USE_SLAVE_CONNECTION sur true pour utiliser une connexion lecture seule à un réplica Valkey pour le trafic en lecture seule, tandis que l’instance principale gère le trafic en lecture-écriture. Cette connexion améliore les performances grâce à l’équilibrage de charge, car un seul nœud gère le trafic en lecture-écriture. Pour supprimer un tableau de connexion en lecture seule existant de env.php, définissez-le sur false.

stage:
  deploy:
    VALKEY_USE_SLAVE_CONNECTION: true

Vous devez avoir configuré un service Valkey en .magento.app.yaml et .magento/services.yaml. La disponibilité d’une connexion de réplication dépend de la topologie du projet et de la version de ece-tools installée.

Avant de vous fier à ce paramètre, examinez la valeur de MAGENTO_CLOUD_RELATIONSHIPS décodée et confirmez qu’une relation de réplication est présente. Par exemple :

echo "$MAGENTO_CLOUD_RELATIONSHIPS" | base64 -d | json_pp

Par symfony_l2, la prise en charge des réplications nécessite les mises à jour appropriées des correctifs ece-tools et Cloud. Effectuez la mise à jour vers la dernière version de ece-tools avant d’activer ce paramètre. Si aucune relation de réplication n’est présente après le redéploiement, contactez l’assistance Adobe Commerce.

Lors de l’utilisation de CACHE_CONFIGURATION, fusionner les remplacements pris en charge dans la configuration générée au lieu de remplacer la structure de connexion générée.

RESOURCE_CONFIGURATION

Mappe un nom de ressource à une connexion à la base de données. Cette configuration correspond à la section resource du fichier env.php.

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne de nouvelles valeurs dans une configuration existante :

stage:
  deploy:
    RESOURCE_CONFIGURATION:
      _merge: true
      default_setup:
        connection: default

SCD_COMPRESSION_LEVEL

Indique le niveau de compression gzip (0 à 9) à utiliser lors de la compression du contenu statique. Définissez-le sur 0 pour désactiver la compression.

stage:
  deploy:
    SCD_COMPRESSION_LEVEL: 5

SCD_COMPRESSION_TIMEOUT

Lorsque le temps nécessaire à la compression des ressources statiques dépasse le délai d’expiration de la compression, le processus de déploiement est interrompu. Définissez la durée d’exécution maximale, en secondes, de la commande de compression de contenu statique.

stage:
  deploy:
    SCD_COMPRESSION_TIMEOUT: 800

SCD_MATRIX

Vous pouvez configurer plusieurs paramètres régionaux par thème. Cette personnalisation accélère le processus de déploiement en réduisant le nombre de fichiers de thème inutiles. Par exemple, vous pouvez déployer le thème magento/backend en anglais et un thème personnalisé dans d’autres langues.

L’exemple suivant déploie le thème Magento/backend avec trois paramètres régionaux :

stage:
  deploy:
    SCD_MATRIX:
      "magento/backend":
        language:
          - en_US
          - fr_FR
          - af_ZA

Vous pouvez également choisir de ne pas déployer thème :

stage:
  deploy:
    SCD_MATRIX:
      "magento/backend": [ ]

SCD_MAX_EXECUTION_TIME

Permet d’augmenter le temps d’exécution maximal attendu pour le déploiement de contenu statique.

Par défaut, Adobe Commerce définit l’exécution maximale prévue sur 900 secondes, mais certains scénarios nécessitent plus de temps pour terminer le déploiement du contenu statique pour un projet cloud.

stage:
  deploy:
    SCD_MAX_EXECUTION_TIME: 3600

SCD_NO_PARENT

Lors de la phase de déploiement, définissez SCD_NO_PARENT: true afin que la génération de contenu statique pour les thèmes parents ne se produise pas pendant la phase de déploiement. Ce paramètre réduit le temps de déploiement et évite les temps d’arrêt du site qui peuvent se produire si la création de contenu statique échoue pendant le déploiement. Voir Déploiement de contenu statique.

stage:
  deploy:
    SCD_NO_PARENT: true

SCD_STRATEGY

Permet de personnaliser la stratégie de déploiement pour le contenu statique. Voir ​ Déploiement de fichiers de vue statiques ​.

Utilisez ces options uniquement si vous disposez de plusieurs paramètres régionaux :

stage:
  deploy:
    SCD_STRATEGY: "compact"

SCD_THREADS

Définit le nombre de threads pour le déploiement de contenu statique. La valeur par défaut est définie en fonction du nombre de threads CPU détectés et ne dépasse pas une valeur de 4. L’augmentation du nombre de threads accélère le déploiement de contenu statique. La diminution du nombre de threads le ralentit. Vous pouvez définir la valeur du thread, par exemple :

stage:
  deploy:
    SCD_THREADS: 2

Pour réduire davantage le temps de déploiement, utilisez Gestion de la configuration avec la commande scd-dump pour déplacer le déploiement statique vers la phase de création.

SEARCH_CONFIGURATION

Utilisez cette variable d’environnement pour conserver les paramètres de service de recherche personnalisés entre les déploiements. Par exemple :

Configuration d’Elasticsearch :

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: elasticsearch
      elasticsearch_server_hostname: http://elasticsearch.internal
      elasticsearch_server_port: '9200'
      elasticsearch_index_prefix: magento2
      elasticsearch_server_timeout: '15'

Configuration d’OpenSearch (pour Commerce 2.4.6 et versions ultérieures) :

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: opensearch
      opensearch_server_hostname: 'http://opensearch.internal'
      opensearch_server_port: '9200'
      opensearch_index_prefix: 'magento2'
      opensearch_server_timeout: '15'

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne une nouvelle valeur avec la configuration existante :

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: elasticsearch
      elasticsearch_server_port: '9200'
      _merge: true

SESSION_CONFIGURATION

Utilisez SESSION_CONFIGURATION pour configurer le stockage de session. L’exemple ci-dessous utilise la structure de configuration de session compatible avec Redis. Utilisez-le uniquement avec la combinaison de noms et de services de stockage de sessions prise en charge par la version exacte de Commerce. Pour les sessions soutenues par Valkey, suivez l’exemple Valkey session-storage example.

Ne supposez pas que les variables de cache telles que VALKEY_BACKEND ou REDIS_BACKEND configurent des sessions. Le cache et la configuration de session sont indépendants. Sur les projets cloud, utilisez la relation de service et la configuration générée si possible ; ne codez pas en dur des valeurs spécifiques à un environnement sans remplacer l’exemple d’hôte et de port.

stage:
  deploy:
    SESSION_CONFIGURATION:
      redis:
        bot_first_lifetime: 100
        bot_lifetime: 10001
        database: 0
        disable_locking: 1
        host: 'redis.internal'
        max_concurrency: 10
        max_lifetime: 10001
        min_lifetime: 100
        port: 6379
      save: redis

Remplacez redis.internal et 6379 par l’hôte et le port du service de session pour l’environnement cible lorsque la configuration de déploiement nécessite des détails de connexion explicites.

Par défaut, le processus de déploiement remplace tous les paramètres du fichier env.php. Vous pouvez toutefois choisir de fusionner une ou plusieurs valeurs pour une configuration de service sans remplacer toutes les valeurs.

Définissez l’option _merge sur l’une des options suivantes :

L’exemple suivant fusionne une nouvelle valeur avec la configuration existante :

stage:
  deploy:
    SESSION_CONFIGURATION:
      _merge: true
      redis:
        max_concurrency: 10

SKIP_SCD

Définissez sur true pour ignorer le déploiement du contenu statique pendant la phase de déploiement.

Lors de la phase de déploiement, définissez SKIP_SCD: true afin que la création de contenu statique ne se produise pas pendant la phase de déploiement. Ce paramètre réduit le temps de déploiement et évite les temps d’arrêt du site qui peuvent se produire si la création de contenu statique échoue pendant le déploiement. Voir Déploiement de contenu statique.

stage:
  deploy:
    SKIP_SCD: true

UPDATE_URLS

Lors du déploiement, remplacez les URL de base d’Adobe Commerce dans la base de données par les URL de projet spécifiées par la variable MAGENTO_CLOUD_ROUTES . Cette configuration est utile pour le développement local, où les URL de base sont configurées pour votre environnement local. Lorsque vous effectuez un déploiement dans un environnement cloud, les URL sont mises à jour afin que vous puissiez accéder à votre storefront et à votre administrateur à l’aide des URL du projet.

Si vous devez mettre à jour des URL lors d’un déploiement dans des environnements d’évaluation et de production Pro ou Starter, utilisez la variable FORCE_UPDATE_URLS .

stage:
  deploy:
    UPDATE_URLS: false

USE_LUA

Contrôle l’option du serveur principal du cache use_lua dans env.php pour le serveur principal du cache par défaut (et, lors de l’utilisation du serveur principal symfony_l2, les options du serveur principal distant du serveur principal du stale_cache_enabled). Cette option n’est pas appliquée au serveur frontal page_cache.

Utilisez la valeur par défaut false sauf indication contraire explicite de la part de la prise en charge d’Adobe.

stage:
  deploy:
    USE_LUA: false

LUA_KEY

La variable LUA_KEY est obsolète. Si LUA_KEY est inclus dans .magento.env.yaml, supprimez-le lors de la migration. Utilisez plutôt les variables USE_LUA et USE_LUA_ON_GC .

USE_LUA_ON_GC

Contrôle l’option du serveur principal du cache use_lua_on_gc dans env.php pour le serveur principal du cache par défaut (et, lors de l’utilisation du serveur principal symfony_l2, les options du serveur principal distant du serveur principal stale_cache_enabled) pour le nettoyage. Cette option n’est pas appliquée au serveur frontal page_cache.

Utilisez l’true de valeur par défaut pour conserver le nettoyage atomique des balises de cache pendant la tâche cron backend_clean_cache.

stage:
  deploy:
    USE_LUA_ON_GC: true

VERBOSE_COMMANDS

Activez ou désactivez le niveau de détail de débogage Symfony pour bin/magento commandes d’interface de ligne de commande exécutées lors de la phase de déploiement.

Choisissez le niveau de détail fourni dans les logs :

stage:
  deploy:
    VERBOSE_COMMANDS: "-vv"