-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue when trying to access our GitHub repo #2689
Comments
Can provide further info as needed. Thanks in advance. |
Hey @delpic thanks for the issue report! There are a couple things you can try to see if they remedy the problem:
Essentially the problem seems to appear when there is network connectivity trouble of some kind. So that might be the first thing to try debugging. If you continue to hit the problem, could you provide the pod YAML that backs the TaskRun? The TaskRun YAML should show you the Pod's name under the kubectl get -o yaml pod testrun-pod-<random letters> |
Thanks for the follow up @sbwsg! I think this issue most likely falls into the second scenario that you mentioned as our GitHub is not on-prem. I tried specifying
I tried troubleshooting further, but no luck. Here is the pod YAML that you requested:
Thanks again for your help! |
Tried the fix, but same result. Though there is a symlink error after introducing the fix from above:
|
Thanks for the great info, this is all very helpful as we debug. So, it appears right now like the credentials are being initialized as we expect them to be. We can tell this because: a) the creds-init initContainer has both the correct arg (-ssh-git=elastic-github-ssh-key=github.com) and mounted secret (mountPath: You mentioned trying the fix from #1271 but could you confirm what the fix was you tried? If you flipped the Here's what I suggest trying next: Run a TaskRun that will give us more insight into what the initialized credentials look like. Here's an example: apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: debug-testrun
spec:
serviceAccountName: elastic-github-build-bot
params:
- name: url
value: [email protected]:xxxxx/elastic.git # TODO: update this url
taskSpec:
params:
- name: url
type: string
steps:
- name: check-creds
image: alpine/git:v2.24.3
script: |
#!/usr/bin/env ash
set -xe
id
for f in /tekton/home/.ssh/* ; do
cat $f
done
ln -s /tekton/home/.ssh /root/.ssh
git clone $(params.url) Update the Once you have the pod logs, take a look at the SSH private key that was printed. Does it match the original you have? If not then this is likely the problem - the key has not survived the translation to base64 in the Secret and back again. If it does match what you have locally then were there any errors from the I'm very curious to hear the outcome from this debugging, please keep me posted. Remember to sanitize the log output of any credentials or other sensitive information if you want to post it here to show findings. |
Thanks @sbwsg! Regarding #1271, I had set the I ran the TaskRun yaml you provided. Here is the error I received:
I can confirm that the private key does match up with the original. As far as permissions go, I added this as a deploy key, but did not give it write access as it will only be used to clone. So something specific to the Git PipelineResource then? |
Hmmm this is really odd. If the SSH key is working then I would have assumed that the git clone should have succeeded.
This seems very much like a network problem to me. To double check this I suggest running a new TaskRun with a script that does apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: debug-testrun
spec:
serviceAccountName: elastic-github-build-bot
params:
- name: url
value: [email protected]:xxxx/elastic.git # TODO: update this url
taskSpec:
params:
- name: url
type: string
steps:
- name: check-creds
image: alpine/git:v2.24.3
script: |
#!/usr/bin/env ash
set -xe
id
ln -s /tekton/home/.ssh /root/.ssh
sleep 3000 Then kubectl exec debug-testrun-pod-<random letters> -c step-check-creds -it /bin/ash This will put you inside the container created for the Task's Step. Then you can run something like this: cd /tekton/home
wget github.com This should get you a response like this: Connecting to github.com (140.82.113.3:80)
Connecting to github.com (140.82.113.3:443)
saving to 'index.html'
index.html 100% |**************************************************************************************************************| 128k 0:00:00 ETA
'index.html' saved If that succeeds then try something like this: Which should net you a response like this: PTY allocation request failed on channel 0
Hi sbwsg/private! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed. Then finally run Also, another question: which platform are you running on? Is this locally in |
Thanks @sbwsg. Doing some further debugging on our end, it seems that we are blocking port 22 on the network that the clusters are running on. Our platform runs on Thank you for all the help you have provided!! |
Expected Behavior
I am expecting that the process running should access the GitHub repo I defined and clone it. Our GitHub account is an Enterprise account.
Actual Behavior
Getting the following error from the
credential-initializer
container:Steps to Reproduce the Problem
Here are the yaml files I created:
Deployed in this order:
Additional Info
Kubernetes version:
Output of
kubectl version
:The text was updated successfully, but these errors were encountered: