After doing so, all pods appear to spin up correctly, CLI access and traffic routing all work fine. However, when doing a git push to deploy a buildpack based app you get output like
Counting objects: 14005, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8079/8079), done.
Writing objects: 100% (14005/14005), 23.71 MiB | 11.46 MiB/s, done.
Total 14005 (delta 8682), reused 9243 (delta 4980)
remote: Resolving deltas: 100% (8682/8682), done.
Starting build... but first, coffee!
...
...
...
...
This goes on and on until the remote end hangs up.
Tailing the logs of deis-builder during one of these builds shows
Accepted connection.
Starting ssh authentication
Failed to authenticate user ssh key bd:f1:02:ff:83:47:62:34:12:8c:a3:54:b3:17:e3:89 with the controller: Not Found
Starting ssh authentication
Channel type: session
Key='LANG', Value='en_US.UTF-8'
receiving git repo name: dev-engage.git, operation: git-receive-pack, fingerprint: 27:9e:40:b1:27:39:fd:01:6f:4c:df:23:a0:54:af:b9, user: drock
creating repo directory /home/git/dev-engage.git
writing pre-receive hook under /home/git/dev-engage.git
git-shell -c git-receive-pack 'dev-engage.git'
Waiting for git-receive to run.
Waiting for deploy.
---> ---> ---> ---> ---> ---> ---> ---> ---> ---> [ERROR] Failed git receive: dev-engage lock exceeded timeout
I was able to see a slugbuilder pod spin up and tail its logs. It did actually fire and built the slug. I also verified that the slug was uploaded to our S3 bucket. It appears as though the deis-builder cannot see the slugbuild however.
I deleted deis using helm and re-installed it in the namespace deis and everything worked again using the same values.yaml file.
If you install deis into another kubernetes namespace other than "deis" builds do not fully work. For example:
After doing so, all pods appear to spin up correctly, CLI access and traffic routing all work fine. However, when doing a git push to deploy a buildpack based app you get output like
This goes on and on until the remote end hangs up.
Tailing the logs of deis-builder during one of these builds shows
I was able to see a slugbuilder pod spin up and tail its logs. It did actually fire and built the slug. I also verified that the slug was uploaded to our S3 bucket. It appears as though the deis-builder cannot see the slugbuild however.
I deleted deis using helm and re-installed it in the namespace deis and everything worked again using the same values.yaml file.