Мб ты что-то сконфигурировал криво?

А какой инструмент лучше helm costumize werf или ансибл lдля работы с кубером через гитлаб ?

qbec хороший

Может... У него битбакет он-премис ?

Tanks ещё от grafanalabs наверное норм, но пока не пробовал

+

Оно называется bitbucket-server

Вполне возможно кстати

Так и у меня был он премис

Там наверняка можно накосячить в настройках

Хотя если обычный гит переваривает редиректы, то импорт гитлаба тоже бы должен

Гитлаб под капотом наполовину состоит несуразностей и костылей, там все возможно

Ну вот да

Ну хз, везде урлы с https указаны, а api отдает ссылку на клонирование с http

Всем салют ! парни, как рашить траблу с кубовым эксзекутором
в общем, если я запускаю джобу БЕЗ environment:name переменной - то у меня все нормально отрабтаывает на раннере и корректно деплоится в кластер. при этом никаких переменных типа KUBE_* я не вижу в энве
если же я использую эту переменную, то у меня сразу экспозятся варсы типа KUBE_NAMESPACE в виде ( In the format <project_name>-<project_id>-<environment> ) и автоматом ломает мой билд потому что $KUBECONFIG передается неверный а именно сервис аккаунт, например

 $ kubectl config view
 apiVersion: v1
 clusters:
 - cluster:
     certificate-authority-data: DATA+OMITTED
     server: https://example.org:6443
   name: gitlab-deploy
 contexts:
 - context:
     cluster: gitlab-deploy
     namespace: backend-96-develop
     user: gitlab-deploy
   name: gitlab-deploy
 current-context: gitlab-deploy
 kind: Config
 preferences: {}
 users:
 - name: gitlab-deploy
   user:
     token: [MASKED]

то есть проставляется некорректный (несуществующий) неймспейс - и идет ругань типа
User "system:serviceaccount:backend-96-develop:backend-96-develop-service-account" cannot get resource "deployments" in API group "extensions" in the namespace "somens"

раннер запущен через хэлм с такими значениями рбак

rbac:
  create: true
  clusterWideAccess: true

не понимаю, как сейчас правильно поступить, чтоб я мог корректно использовать environment переменные

Так ты можешь использовать переменные, кроме KUBE_NAMESPACE. Была похожая проблема, я решил как-то так:

  variables:
    KUBE_CONFIG: $CUSTOM_KUBE_CONFIG
  script:
    - echo $KUBE_CONFIG | base64 -d > $KUBECONFIG

  variables:
    KUBE_CONFIG: $CUSTOM_KUBE_CONFIG
  script:
    - echo $KUBE_CONFIG | base64 -d > $KUBECONFIG

хм, как вариант, но хотелось чтоб он сам корректный кубконфиг экспозил
кстати без environment name у меня вообще вот так выдает

 $ kubectl config view
 apiVersion: v1
 clusters: []
 contexts: []
 current-context: ""
 kind: Config
 preferences: {}
 users: []

но в этом случае - деплой отрабатывает в нужном кластере