build context in private gitlab repository

[bitsofinfo]

is there anyway to pull build context from a private gitlab repo?

[SamyCoenen]

kaniko/pkg/buildcontext/git.go

Line 37 in 32b3b4f

options := git.CloneOptions{

kaniko/pkg/buildcontext/git.go

Line 44 in 32b3b4f

_, err := git.PlainClone(directory, false, &options)

I don't think so

[tejal29]

@bitsofinfo, @SamyCoenen is correct. there is no way as of now.
The team has higher priority issues to look at the moment and hence we can't get to it soon.
PRs welcomed!

[twDuke]

Does this affect cloning from private azure devops repos?
Getting
Error: error resolving source context: unexpected client error: unexpected requesting
https://#TOKEN#@somegitrepo/git-upload-pack" status code: 400

Edit: If someone could point me in the right direction, I will take a stab at solving it. take

[twDuke]

If I understand everything correctly it seems to be related to
src-d/go-git#1058
Given this, it seems that solving it using go-git will be hard before they add support for git protocol-v2
with that in mind the options would be

1. Install git in the docker image. Then either:
   1.a Clone the git repo before starting kaniko and in kaniko treat it as a local context
   1.b Fork git cli from the kaniko process

[artbegolli]

Looks like support for private repositories has been recently added through setting the GIT_USERNAME and GIT_PASSWORD environment variables - here's the PR #1263

Seems like there's probably a bit of room to document it more clearly in the README - I'll create a PR.

[xkfen]

same problem in private gitlab. but i can use kaniko in private github.

` containers:

• name: kaniko
  image: gcr.io/kaniko-project/executor:debug
  args: ["--verbosity=trace",
  "--dockerfile=Dockerfile",
  "--context=git://git.xxx.cn/username/stack.git#refs/heads/dev",
  "--destination=registry.local/kaniko/buildpack-linux-nginx:v11"]
  env:
  • name: GIT_PULL_METHOD
    value: http
  • name: GIT_TOKEN
    value: accesstoken
  • name: GIT_USERNAME
    value: username
  • name: GIT_PASSWORD
    value: accesstoken
    `

but i got this err:
DEBU[0000] Getting source context from git://git.xx.cn/username/stack.git#refs/heads/dev
DEBU[0000] Getting source from reference refs/heads/dev
Error: error resolving source context: authentication required

any help?

[gretel]

@xkfen please have a look https://github.com/GoogleContainerTools/kaniko#using-private-git-repository

[xkfen]

@xkfen please have a look https://github.com/GoogleContainerTools/kaniko#using-private-git-repository

thanks for you apply. the readme shows that the private git repository can either use git://token@xxx or use env GIT_TOKEN，the two methods both give me the err: authentication required
my gitlab use http.

[psreddy22]

facing same issues !! Any thing working process ??

[klojtas]

I'm also facing a problem against context in private azure devops repo.

[keshamin]

Also would like to use kaniko with internal private GitLab.

[pingcrosby]

me too ...
Same issue.

[neckos]

Works for me in argo workflow template to fetch private Gitlab repo

Pass only this one env

name: GIT_PASSWORD
value: accesstoken

and keep context in this format

--context=git://xxx.xxx.xx/user/project.git

[StepanKuksenko]

Works for me in argo workflow template to fetch private Gitlab repo

Pass only this one env

name: GIT_PASSWORD
value: accesstoken

and keep context in this format

--context=git://xxx.xxx.xx/user/project.git

this solution works for v1.6.0 kaniko version only. Broken in v1.7.0
need to use gcr.io/kaniko-project/executor:v1.6.0 tag, don't use the debug one, it also doesn't work since it was built from v1.7.0 i suppose.

[pcgeek86]

I also need this functionality.

[SergeyBear]

Seems to work fine on latest kaniko 1.8.1 with GIT_USERNAME and GIT_PASSWORD env vars

[mattduguid]

The doco https://github.com/GoogleContainerTools/kaniko/blob/main/README.md#using-private-git-repository states "You can use Personal Access Tokens for Build Contexts from Private Repositories from GitHub." ...does that mean only GitHub and nothing else?

We have been attempting to use kaniko and git context but from a private Azure Devops git repo but get error http/400 (bad request) for /git-upload-pack -> https://git-scm.com/docs/git-upload-pack

DEBU[0000] Getting source context from git://<OUR_INSTANCE>.visualstudio.com/<OUR_PROJECT>/_git/<OUR_REPO>
DEBU[0000] Getting source from reference                
Error: error resolving source context: unexpected client error: unexpected requesting "https://<OUR_INSTANCE>.visualstudio.com/<OUR_PROJECT>/_git/<OUR_REPO>/git-upload-pack" status code: 400

UPDATE: tested same but using a private github repo and GIT_TOKEN variable and it works

DEBU[0000] Getting source context from git://github.com/mattduguid/helloworld.git 
DEBU[0000] Getting source from reference                
Enumerating objects: 3240, done.
Counting objects:   0% (1/3240)
...etc...

UPDATE: microsoft acknowledge the issue but wont be changing things at their end confirmed here fluxcd/source-controller#104 (comment) and in microsoft ticket 22962210190030002812

WORKAROUND 02/11/22: similar solution to @twDuke we ended using an init container in the kubernetes deployment to run before kaniko container and to git clone the azure devops repo to deployment volume visible to both

[skype007]

@mattduguid How did you manage to git-clone the Azure DevOps repo using initContainers ? I'm interested 👍

Because we're in a situation, due to technical constraints, where we want to deploy a Kaniko Pod from Azure Pipeline CI (using a Self Hosted agent running inside a Pod Kubernetes) and we're not unable to use the "context" locally :(

What I tried (but it seems it's a dead end):

• When a pipeline run, it tries to package the source code as a tarball and then deploy the YAML kaniko pod (hard-written in the DevOps YAML pipeline) by mounting volume from hostPath (I supposed it would be the "file system" of my DevOps agent since the tarball is there)
• When a pipeline run, it tries to deploy the YAML kaniko pod by pointing to the source code already checkout by AzureDevOps (so I could use context=dir:///workspace)

The goal of this approach in the end is to try to let kaniko build our image without pushing it somewhere if possible (so we can use the produced image in .tar format in whatever way we please - scan the image for example)

Doesn't work :( I don't know if it's "normal" it can't work or it could but I may be doing something wrong?

[mattduguid]

@skype007 used the following, the syntax is HCL from our terraform resource "kubernetes_manifest" for a manifest kind of "deployment",

• "ubuntu:latest" for the init container (could use any other container meeting requirements) and "gcr.io/kaniko-project/executor:latest" for the kaniko container
• both the init and kaniko container set to have the same shared volume, we had some issues using volume name /workspace so changed it to /clone,

"volumeMounts" = [
{
    "mountPath" = "/clone"
    "name" = "clone"
},
<SHORTENED>
]

• in the init container used a multi line "arg" parameter to install git and anything else required then did a clone using an azure devops token to the shared volume,

"args" = [
<<-EOT

echo -e "\n- [update/upgrade package manager]\n"
apt-get update --fix-missing && apt-get upgrade

echo -e "\n- [clear /clone]\n"
rm -r -f -v /clone/*

echo -e "\n- [git install & clone]\n"
apt-get -y install git

# clone from azure devops
git clone https://<TOKEN>@<OUR_INSTANCE>.visualstudio.com/<OUR_PROJECT>/_git/helloworld /clone

# clone from github ***used to test***
# git clone https://<TOKEN>@github.com/mattduguid/helloworld.git /clone

echo -e "\n- [show /clone]\n"
ls -l /clone

EOT
]

• then in the kaniko container in the "args" set the "--context" to the shared volume and that was it, worth noting we initially saw some very slow build times so added args "--single-snapshot", "--snapshot-mode=redo", "--use-new-run" which definitely speed things up but research those as there are some caveats,

"args" = [
      "--context=dir:///clone", 
      "--dockerfile=appHelloWorld/Dockerfile",
      "--destination=k8s-registry.k8s-registry.svc.cluster.local/helloworld:1.0.3",
      <SHORTENED>
      "--single-snapshot", # added because kaniko was taking a snapshot for every single docker command and this will force only 1 at the end
      "--snapshot-mode=redo", # up to 50% faster?
      "--use-new-run" # use the experimental run implementation for detecting changes without requiring file system snapshots. In some cases, this may improve build performance by 75%.
]

Not the most ideal solution but it has unblocked us for now. Hope that helps 👍

[skype007]

@mattduguid Thank you for your sample ;) Only the "git clone" didn' work for me as it still asked me about Username/Password even if I passed the PAT token.

So in my pipeline I managed to make it work using this (in initContainers):

initContainers:
          - name: git-clone
            image: alpine:3.16.2
            command: ["sh", "-c"]
            args: 
            - |
              apk add --no-cache git &&
              git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --depth 1 https://'OrgName'@dev.azure.com/'OrgName'/'ProjectName'/_git/'RepoName' /workspace
            volumeMounts:
            - name: build-context
              mountPath: /workspace

Like you said, better than nothing !

Hope it can help someone facing the same issue !

[ianthetechie]

As far as I can tell, it does work with the latest kaniko debug executor releases. However, in my case the problem turned out to be with the GitLab side. When creating your project access token, you need to give it developer access; guest access isn't enough. This is horribly confusing since you can give it read_repository permissions but without a higher role, it still won't be able to clone.

I set the following env vars in my pipeline:

• GIT_PULL_METHOD=HTTPS
• GIT_USERNAME=<your-token-name> (though per the docs, I think any non-blank username works)
• GIT_PASSWORD=<your-project-access-token>

[xsqian]

@ianthetechie This is really helpful. For "though per the docs, I think any non-blank username works", which docs are you referring to? Thanks!

[yydance]

I'm also facing a problem against context in private gitlab repo using GIT_TOKEN. It works fine on latest kaniko with GIT_USERNAME and GIT_PASSWORD env vars。

[yydance]

I'm also facing a problem against context in private gitlab repo using GIT_TOKEN. It works fine on latest kaniko with GIT_USERNAME and GIT_PASSWORD env vars。

Seems like it doesn't support gitlab