Merge branch '58-improve-delivery' into 'master'

Resolve "(ci) improve delivery"

Closes #58 and #24

See merge request lydra/gitlab-ci-templates!42

.gitlab-ci.yml

@@ -6,28 +6,23 @@ include:
   - '/templates/activate-dind.yml'
   - '/templates/stages.yml'
   - '/templates/job/ci/images_list.yml'
+  - '/templates/job/node/build.yml'
+  - '/templates/job/node/lint.yml'
+  - '/templates/job/node/test.yml'
   - '/templates/job/java/lint.yml'
   - '/templates/job/java/build.yml'
   - '/templates/job/container/build.yml'
   - '/templates/job/container/lint.yml'
   - '/templates/job/container/delivery.yml'
+  - '/templates/job/ansible/lint.yml'
+  - '/templates/job/ansible/role-test.yml'
+  - '/templates/job/bash/lint.yml'
+  - '/templates/job/bash/test.yml'
+  - '/templates/job/yaml/lint.yml'
+  - '/templates/job/terraform/lint.yml'
 # Deprecated templates
   - '/gci-templates/job/info.yml'
   - '/gci-templates/job/.base.yml'
-  - '/gci-templates/job/ansible/lint.yml'
-  - '/gci-templates/job/ansible/role-test.yml'
-  - '/gci-templates/job/bash/lint.yml'
-  - '/gci-templates/job/bash/test.yml'
-  - '/gci-templates/job/yaml-lint.yml'
-  - '/gci-templates/job/terraform/lint.yml'
-  - '/gci-templates/job/node/build.yml'
-  - '/gci-templates/job/node/lint.yml'
-  - '/gci-templates/job/node/test.yml'
-  - '/gci-templates/job/ansible-lint.yml'
-  - '/gci-templates/job/bash-lint.yml'
-  - '/gci-templates/job/bats.yml'
-  - '/gci-templates/job/ansible-syntax-check.yml'
-  - '/gci-templates/job/molecule.yml'
 
 ansible-lint:
   variables:
@@ -67,7 +62,7 @@ container:build:my-image:
   variables:
     IMAGE_NAME: "my-image"
 
-container::lint:
+container:lint:
   variables:
     working_directory: "test/container"
 
@@ -81,21 +76,21 @@ container:delivery:my-image:
     IMAGE_NAME: "my-image"
 
 # --------[ Node ]--------
-node::build:
+node:build:
   variables:
     working_directory: "test/node/vueapp"
   cache:
     paths:
       - test/node/vueapp/node_modules
 
-node::lint:
+node:lint:
   variables:
     working_directory: "test/node/vueapp"
   cache:
     paths:
       - test/node/vueapp/node_modules
 
-node::test:
+node:test:
   variables:
     working_directory: "test/node/vueapp"
   cache:

README-fr.md

@@ -17,23 +17,38 @@ Pour utiliser ce dépôt vous devez connaître les notions suivantes :
 ## Organisation du dépôt
 
 ```bash
+├── doc
+├── templates
 ├── gci-templates
 └── test
 ```
 
 
+### doc
+
+Ce répertoire contient les documentations du projet.
+
+
 ### gci-templates
 
 Ce répertoire contient tous les templates qui peuvent être utilisés dans les piplines.
 
+
+### gci-templates
+
+Ce répertoire contient tous les anciens templates qui pouvais être utilisés dans les piplines.
+⚠️ Ce repertoire est déprécié.
+
+
 #### activate-dind.yml
 
 Ce fichier permet d’activer docker in docker.
 Tous les jobs de ce dépôt utilisent docker.
 
+
 #### stages.yml
 
-Ce fichier contient la définition des stages et des templates de base utilisés dans les jobs.
+Ce fichier contient la définition des stages et des templates de bases utilisés dans les jobs.
 
 
 #### job
@@ -53,7 +68,8 @@ Pour utiliser les _templates_ de CI de ce dépôt il faut les inclure dans le fi
 
 Chaque fichier contient un, ou plusieurs, jobs classés en fonction de leur thématique.
 
-Pour avoir des exemples d'implémentation vous avez [ce groupe qui contient des dépôts d'exemples](https://lab.frogg.it/froggit/ci/examples).
+Pour avoir des exemples d'implémentation vous avez [ce groupe qui contient des dépôts d'exemples](https://xc001xg9.siege.intra.groupe-casino.fr/ci-cd/exemples).
+
 
 ### `stages.yml`
 
@@ -64,7 +80,7 @@ Il contient aussi les modèles de base des jobs.
 Vous pouvez utiliser ces modèles pour concevoir vos propres jobs.
 
 ```yaml
-node::test:
+node:test:
   extends: .base_tpl
   stage: test
   script:
@@ -75,7 +91,7 @@ node::test:
 
 #### Les étapes
 
-##### Info
+##### info
 
 Cette étape sert à informer les utilisateurs de la CI.
 On peut y mettre un peu ce que l'on veut.
@@ -87,6 +103,7 @@ Vous pouvez dans votre CI vous en servir par exemple pour :
 
 Vous avez à disposition 3 jobs modèles qui utilisent tous "Docker in Docker".
 
+
 ###### `.info`
 
 Ce job affiche un message et se termine en succès.
@@ -127,6 +144,7 @@ Mon warning dans test:
 ##### Build
 
 Cette étape contient tous les jobs de build de l'application.
+Elle génère souvent des fichiers caches.
 
 
 ##### Lint
@@ -134,6 +152,12 @@ Cette étape contient tous les jobs de build de l'application.
 Cette étape contient tous les jobs de lint.
 
 
+##### Package
+
+Cette étape contient tous les jobs de packaging des applications.
+C'est souvent la création des images de conteneurs temporaires.
+
+
 ##### Test
 
 Cette étape contient tous les jobs de tests.
@@ -143,17 +167,19 @@ Cette étape contient tous les jobs de tests.
 
 Cette étape contient tous les jobs d’empaquetage des applications :
 - Création des  _releases_.
-- Création des images de conteneurs et _push_ dans le registre du dépôt.
+- Création des images de conteneurs et _push_ dans le registre du dépôt, et dans le registre de production.
 - Mise à disposition des  _releases_ ou paquet dans un dépôt d'artefact.
  
 Les jobs de cette étape n'existent que lorsqu'un tag est poussé sur le dépôt GitLab.
 
 
+[🔎 Pour approfondir.](doc/fr/livraison.md)
+
+
 ##### Deploy
 
 Cette étape contient tous les jobs de déploiement des applications :
 - Envoi du code sur un serveur distant.
-- _Push_ des images de conteneurs dans le registre de production.
  
 Les jobs de cette étape n'existent que lorsqu'un tag est poussé sur le dépôt GitLab et ils sont **à déclenchement manuel**.
 
@@ -163,7 +189,7 @@ Les jobs de cette étape n'existent que lorsqu'un tag est poussé sur le dépôt
 Ce dépôt tire partie des fonctionnalités d'[include](https://docs.gitlab.com/ce/ci/yaml/#include) et d'[extends](https://docs.gitlab.com/ce/ci/yaml/#extends) de GitLab-CI pour rendre le code modulaire.
 Il est important de les connaître pour mètre en place les _templates_ et pouvoir faire de l'héritage.
 
-Les jobs modèles commencent tous par un point (`.`) et ne sont pas destinés à être utilisés tels quels.
+Les jobs modèle commencent tous par un point (`.`) et ne sont pas destinés à être utilisés tels quels.
 Pour GitLab ce sont des [jobs cachés](https://docs.gitlab.com/ee/ci/yaml/README.html#hide-jobs) et ils ne sont pas exécutés dans la CI.
 Par contre n'importe quel job peut en hériter grâce au mot clef `extends`.
 
@@ -180,7 +206,7 @@ Par exemple pour builder deux images docker donc les Dokerfiles sont `front/Doke
 # .gitlab-ci.yml
 
 include:
-  - project: 'lydra/gitlab-ci-templates'
+  - project: 'ci-cd/gci-tpl'
     ref: master
     file:
       - '/templates/stages.yml'
@@ -212,31 +238,30 @@ Par exemple les `variables:` s’additionnent là ou les `tags:` ou le `script:`
 ##### Exemple d'utilisation
 
 Je veux utiliser `npm ci` à la place de `yarn build` pour construire mon application node.
-Il faut donc que je surcharge le script du job `node::build`.
+Il faut donc que je surcharge le script du job `node:build`.
 
 Mon `.gitlab-ci.yml` devra être comme ça :
 
 ```yaml
 # .gitlab-ci.yml
-
 include:
-  - project: 'lydra/gitlab-ci-templates'
+  - project: 'ci-cd/gci-tpl'
     ref: master
     file:
       - '/templates/stages.yml'
       - '/templates/job/node/build.yml'
 
-node::build:
+node:build:
   script:
     - npm ci
 ```
 
-Seule la partie script sera modifiée, toute le reste de la définition du job `node::build` sera comme dans le fichier `https://gitlab.com/lydra/gitlab-ci-templates/-/raw/master/gci-templates/job/node/build.yml`
+Seule la partie script sera modifiée, toute le reste de la définition du job `nodebuild` sera comme dans le fichier `https://gitlab.com/lydra/gitlab-ci-templates/-/raw/master/templates/job/node/build.yml`
 
 Ce qui donne comme résultat :
 
 ```yaml
-node::build:
+node:build:
   image: node:14.15.4-slim
   stage: build
   variables:
@@ -247,7 +272,7 @@ node::build:
     paths:
       - node_modules
   before_script:
-    - cd ${working_directory}
+    - cd $working_directory
   script:
     - npm ci
 ```
@@ -264,6 +289,5 @@ Source : https://docs.gitlab.com/ee/user/packages/container_registry/#delete-ima
 ## Pour aller plus loin
 - [La référence de `.gitlab-ci.yml`](https://docs.gitlab.com/ce/ci/yaml).
 
-
 ---
 Création graphique par [Freepik](https://www.freepik.com) sur [www.flaticon.com](https://www.flaticon.com) sous licence [CC 3.0 BY](http://creativecommons.org/licenses/by/3.0)

doc/fr/livraison.md

+# Livraison
+
+## Vocabulaire
+
+- **Livraison :** une livraison est la mise à disposition d'un artefact, comme une archive compressée (tgz, jar ou war) ou image de conteneur. Cet artefact est destiné à être installé sur les environnements d’exécution. Quand elle est automatisée on parle de [livraison continue](https://fr.wikipedia.org/wiki/Livraison_continue) (CD : [Continuous Delivery](https://en.wikipedia.org/wiki/Continuous_delivery))
+- **Déploiement :** un déploiement est l'installation environnement d’exécution. On prend souvent le résultat de la livraison pour l’installé sur les serveurs ou lancer des images dans Kubernetes. Quand il est automatisé on parle de [déploiement continu](https://fr.wikipedia.org/wiki/D%C3%A9ploiement_continu) (CD : [Continuous Deployement](https://en.wikipedia.org/wiki/Continuous_deployment))
+
+## Description de la Livraison standard
+
+Ce sont les évènements git qui déclenchent la livraison. En, fonction de l’évènement déclencheur les jobs ne font pas les mêmes actions.
+
+### Artefact
+
+Un artefact est un ensemble de fichier mis à disposition pour une livraison. Un artefact peut-être inclus dans une _release_.
+Dans notre exemple le résultat de la livraison est une image de conteneur car c’est le cas standard mais cela peu être un autre type d’artefact comme une archive jar.
+
+### Branche de fonctionnalité
+
+A chaque `git push` sur GitLab dans une branche de fonctionnalité le pipeline génère une image temporaire dans le registre de conteneur du projet aillant comme nom :
+`mon_projet/branche-<nom_branche>:tmp-branch-<nom_de_branche>-<hash_court>`
+
+### Fusion dans la branche principale
+
+A chaque _merge_ suite à une _Merge Request_ dans GitLab dans la branche principale _master_ ou _main_ (à partir de [GitLab 14](https://docs.gitlab.com/ee/user/project/repository/branches/default.html)) le pipeline génère une image temporaire dans le registre du projet aillant comme nom :
+`mon_projet:tmp-branch-<nom_de_branche>-<hash_court>`
+
+### Création d’un tag
+
+La création d’un tag est souvent un des prémices à la création d’une _release_. Un tag est régulièrement un numéro de version.
+À chaque _merge_ suite à une _Merge Request_ dans GitLab dans la branche principale _master_ ou _main_ (à partir de [GitLab 14](https://docs.gitlab.com/ee/user/project/repository/branches/default.html)) le pipeline génère une image dans le registre de conteneur :
+- du projet aillant comme nom : `mon_projet:<tag>`
+- du dépôt des images de livraison aillant comme nom : `mon_projet:<tag>`
+
+Voir [les normes de nommage d’images de conteurs](https://gitpr01.siege.intra.groupe-casino.fr/developpement/gitlab-casino/-/blob/master/Images_docker_casino.md).
+
+Ce comportement est modifiable, voir [le job container:delivery](../templates/job/container/delivery.yml) pour plus de précisions.

gci-templates/job/container/build.yml

+# docs:
+#   - https://docs.gitlab.com/ee/ci/docker/using_kaniko.html
+#   - https://cloud.google.com/build/docs/kaniko-cache
+#
+# This job use kaniko with cache
+# The image is taged with tmp-latest-${CI_COMMIT_SHA}
+#
+# Activate the container registery cleanup policy if you are on GitLab
+# doc : https://docs.gitlab.com/ee/user/packages/container_registry/#delete-images-by-using-a-cleanup-policy
+#
+# variables:
+#   IMAGE_NAME: is the name of the image to build
+#   CONTAINER_CACHE_TTL: cache expiration delay time to live, default :6 hours
+
+container:build:
+  extends:  .container:build
+  stage:    package

gci-templates/job/container/delivery.yml

-# doc: https://docs.gitlab.com/ee/ci/docker/using_kaniko.html
+# docs:
+#   - https://docs.gitlab.com/ee/ci/docker/using_kaniko.html
+#   - https://cloud.google.com/build/docs/kaniko-cache
+#
+# Ce job utilise kaniko avec le cache
+# L'image sera toujours tagué avec le tag de git et latest
+# dans le(s) registre(s) destination(s)
+# L'image est livré dans le registre de conteneur du projet
+# mais peut-être livré en plus dans un registre de livraison
+#
 # variables:
-#   IMAGE_NAME: is the name of the image to build
-# The image is taged like the git tag or latest if the tag don't exist.
+#   IMAGE_NAME: c'est le nom de l'image généré
+#   CONTAINER_CACHE_TTL: durée de vie du cache, défaut : 6 hours
+#   DELIVERY_REGISTRY:            c'est le registre de conteneur de livraison suplémentaire
+#   DELIVERY_REGISTRY_USER:       utilisateur du registre de conteneur de livraison
+#   DELIVERY_REGISTRY_PASSWORD:   mot de passe du registre de conteneur de livraison
+#   DELIVERY_REGISTRY_NAMESPACE:  Namespace de destination de l'image dans le registre de conteneur de livraison
+#                                 par défaut c'est le même que le dépôt d'origine ${CI_PROJECT_PATH}
 
 container:delivery:
-  extends:  .base_tpl
-  image:
-    name: gcr.io/kaniko-project/executor:debug
-    entrypoint: [""]
-  stage: delivery
+  extends:  .container:build
+  stage:    delivery
   rules:
     - if: $CI_COMMIT_TAG
     - if: '$CI_COMMIT_BRANCH == "master"'
     - if: '$CI_COMMIT_BRANCH == "main"'
-  script:
-    - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"username\":\"${CI_REGISTRY_USER}\",\"password\":\"${CI_REGISTRY_PASSWORD}\"}}}" > /kaniko/.docker/config.json
-    - container_image_name=${CI_REGISTRY_IMAGE}/${IMAGE_NAME}:${CI_COMMIT_TAG:-latest}
-    - echo "Build image ${container_image_name}"
-    - /kaniko/executor --context "." --destination ${container_image_name}

gci-templates/job/container/lint.yml

 # doc: https://github.com/hadolint/hadolint
 container::lint:
   extends:  .base_tpl
-  image:    hadolint/hadolint:2.0.0-alpine
+  image:    hadolint/hadolint:2.3.0-alpine
   stage:    lint
   variables:
     files_to_lint: ""
   script: |
-    for dokerfile in "${files_to_lint} $(find . -name "Dockerfile*")"; do
-      echo "----> Container: lint ${dokerfile}"
-      hadolint ${dokerfile}
+    for file in "${files_to_lint} $(find . -name "Dockerfile*")"; do
+      echo "----> Container: lint ${file}"
+      hadolint ${file}
       echo -e "\e[32m  -> Container: lint OK\e[0m"
     done

templates/job/container/delivery.yml

@@ -3,11 +3,19 @@
 #   - https://cloud.google.com/build/docs/kaniko-cache
 #
 # This job use kaniko with cache
-# The image is taged with the git tag or latest if the tag don't exist.
+# The image will always be tagged with the git and latest tag 
+# in the destination registry(s).
+# The image is delivered in the project container registry 
+# but may additionally be delivered in a delivery registry
 #
 # variables:
 #   IMAGE_NAME: is the name of the image to build
-#   CONTAINER_CACHE_TTL: cache expiration delay time to live, default :6 hours
+#   CONTAINER_CACHE_TTL: cache expiration delay time to live, default: 6 hours
+#   DELIVERY_REGISTRY:            additionnal delivery container registry
+#   DELIVERY_REGISTRY_USER:       additionnal registry user
+#   DELIVERY_REGISTRY_PASSWORD:   additionnal registry password
+#   DELIVERY_REGISTRY_NAMESPACE:  additionnal delivery container registry destination namespace
+#                                 Default is the same of namespace of the GitLab git registry
 
 container:delivery:
   extends:  .container:build

templates/job/container/lint.yml

 # doc: https://github.com/hadolint/hadolint
-container::lint:
+container:lint:
   extends:  .base_tpl
   image:    hadolint/hadolint:2.0.0-alpine
   stage:    lint

templates/job/node/build.yml

-node::build:
+node:build:
   extends:
     - .base_node
     - .node-cache-push

templates/job/node/lint.yml

-node::lint:
+node:lint:
   extends:  .base_node
   stage:    lint
   script:

templates/job/node/test.yml

-node::test:
+node:test:
   extends:  .base_node
   stage:    test
   script:

templates/stages.yml

@@ -8,7 +8,7 @@ stages:
   - deploy
 
 variables:
-  working_directory: "$CI_PROJECT_DIR"
+  working_directory: "${CI_PROJECT_DIR}"
   tpl_directory: "gci-templates"
   MAVEN_OPTS: ""
   MAVEN_CLI_OPTS: ""
@@ -22,7 +22,7 @@ variables:
 # /!\ removed soon /!\
 .base_tpl:
   variables:
-    working_directory: "$CI_PROJECT_DIR"
+    working_directory: "${CI_PROJECT_DIR}"
   before_script:
     - cd ${working_directory}
 
@@ -103,39 +103,101 @@ variables:
   image:
     name: gcr.io/kaniko-project/executor:debug
     entrypoint: [""]
+  variables:
+    KANIKOCFG: |
+      "auths": {
+        "${CI_REGISTRY}": {
+          "username": "${CI_REGISTRY_USER}",
+          "password": "${CI_REGISTRY_PASSWORD}"
+        },
+        "${DELIVERY_REGISTRY}": {
+          "username": "${DELIVERY_REGISTRY_USER}",
+          "password": "${DELIVERY_REGISTRY_PASSWORD}"
+        }
+      }
+    KANIKOPROXYBUILDARGS: ""
+    KANIKOPROXYCFG: |
+      "proxies": {
+        "default": {
+          "httpProxy": "${http_proxy}",
+          "httpsProxy": "${https_proxy}"
+        }
+      }
+    CONTAINER_CACHE_NAME: ${CI_REGISTRY_IMAGE}/cache
   script:
     - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"username\":\"${CI_REGISTRY_USER}\",\"password\":\"${CI_REGISTRY_PASSWORD}\"}}}" > /kaniko/.docker/config.json
-    - |- # Image name and tags, use tmp tag on release branch
-        container_cache_name=${CI_REGISTRY_IMAGE}/cache
-        container_default_tag="tmp-branch-${CI_COMMIT_BRANCH}-$(echo ${CI_COMMIT_SHA} | cut -c1-8)"
-
-        if [[ ${CI_COMMIT_BRANCH} != "master" ]] && [[ ${CI_COMMIT_BRANCH} != "main" ]]; then
-          CI_REGISTRY_IMAGE="${CI_REGISTRY_IMAGE}/branch-${CI_COMMIT_BRANCH}"
+    - |- # Test DELIVERY_REGISTRY_* vers
+        delivery_cr=0
+        if [[ "${CI_JOB_STAGE}" != "delivery" ]]; then
+          DELIVERY_REGISTRY=""
+        elif [[ -n "${DELIVERY_REGISTRY}" ]]; then
+          if [[ -z "${DELIVERY_REGISTRY_USER}" ]]; then
+            echo "DELIVERY_REGISTRY=${DELIVERY_REGISTRY} you must declare DELIVERY_REGISTRY_USER !"
+            delivery_cr=1
+          fi
+          if [[ -z "${DELIVERY_REGISTRY_PASSWORD}" ]]; then
+            echo "DELIVERY_REGISTRY=${DELIVERY_REGISTRY} you must declare DELIVERY_REGISTRY_PASSWORD !"
+            delivery_cr=1
+          fi
+          if [[ ${delivery_cr} -ne 0 ]]; then
+            false
+          fi
         fi
-
-        if [[ -z ${IMAGE_NAME} ]]; then
-          container_image_name="${CI_REGISTRY_IMAGE}"
+    - |- # Proxy configuration
+        if [[ "x${http_proxy}" != "x" -o "x${https_proxy}" != "x" ]]; then
+          KANIKOCFG="${KANIKOCFG}, ${KANIKOPROXYCFG}"
+          KANIKOPROXYBUILDARGS="--build-arg http_proxy=${http_proxy} --build-arg https_proxy=${https_proxy} --build-arg no_proxy=${no_proxy}"
+        fi
+        KANIKOCFG="{ ${KANIKOCFG} }"
+        echo "${KANIKOCFG}" > /kaniko/.docker/config.json
+    - |- # Namespace
+        if [[ "${CI_JOB_STAGE}" == "delivery" ]]; then
+          container_namespace="${CI_PROJECT_PATH}"
         else
-          container_image_name="${CI_REGISTRY_IMAGE}/${IMAGE_NAME}"
+          container_namespace="${CI_PROJECT_PATH}/branch-${CI_COMMIT_REF_NAME}"
         fi
-
-        tags="${CI_COMMIT_TAG:-${container_default_tag}} latest"
-    - |- # Build container with Kaniko
+    - |- # Name
+        if [[ -n "${IMAGE_NAME}" ]]; then
+          container_image_name="/${IMAGE_NAME}"
+        else
+          container_image_name=""      
+        fi
+    - |- # Tags
+        container_default_tag="tmp-branch-${CI_COMMIT_REF_NAME}-$(echo ${CI_COMMIT_SHA} | cut -c1-8)"
+        if [[ "${CI_JOB_STAGE}" != "delivery" ]]; then
+          container_tags="${container_default_tag}"
+        else
+          container_tags="${CI_COMMIT_TAG:-${container_default_tag}} latest"
+        fi
+    - |- # Destinations
+        full_image_name=${container_namespace}${container_image_name}
         echo "⚙️ Build image"
-        echo "   📦  name : ${container_image_name}"
-        echo "   💾 cache : ${container_cache_name}"
-        for tag in ${tags}; do
-          echo "     🏷️ tag : ${tag}"
-          destinations="${destinations} --destination=${container_image_name}:${tag}"
+        echo "  💾    cache : ${CONTAINER_CACHE_NAME}"
+        echo "  🏭 registry : ${CI_REGISTRY}"
+        echo "  📦     name : ${full_image_name}"
+        for tag in ${container_tags}; do
+          echo "       🏷️ tag : ${tag}"
+          destinations="${destinations} --destination=${CI_REGISTRY}/${full_image_name}:${tag}"
         done
-        /kaniko/executor \
+
+        if [[ -n "${CI_COMMIT_TAG}" ]] && [[ -n "${DELIVERY_REGISTRY}" ]]; then
+          full_image_name=${DELIVERY_REGISTRY_NAMESPACE:-${container_namespace}}${container_image_name}
+          echo "  🏭 registry : ${DELIVERY_REGISTRY}"
+          echo "  📦     name : ${full_image_name}"
+          for tag in ${container_tags}; do
+            echo "       🏷️ tag : ${tag}"
+            destinations="${destinations} --destination=${DELIVERY_REGISTRY}/${full_image_name}:${tag}"
+          done
+        fi
+    - |- # Build and delivery conainer with Kaniko
+        /kaniko/executor --skip-tls-verify \
           --context "." \
           --cache=true \
           --cache-ttl=${CONTAINER_CACHE_TTL} \
-          --cache-repo=${container_cache_name} \
+          --cache-repo=${CONTAINER_CACHE_NAME} \
+          ${KANIKOPROXYBUILDARGS} \
           ${destinations}
-        
+
 
 # --------[ Info ]--------
 .info: