Pipeline: Creds-init container process caused "invalid value "tekton-ssh-key={my own gitlab domain name}" for flag -ssh-git: exit status 1"

Created on 24 Sep 2019  Â·  13Comments  Â·  Source: tektoncd/pipeline

Expected Behavior

The task run normally.

Actual Behavior

The creds-init container step-credential-initializer (using the image of gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/creds-init@sha256:c8544b7182b53608f7b71f42c31295d8bf534ceeed14be735977c7e289fd37b7) is alway Error !

Steps to Reproduce the Problem

  1. Follow the step: https://github.com/tektoncd/pipeline/blob/master/docs/tutorial.md#task-inputs-and-outputs
  2. For the url of git PipelineResource, I use a domain of self-hosted instance of GitLab such as 'test.gjq.com', rather than the 'gitlab.com' or 'github.com'
  3. my secret of git ssh-auth looks like this:
apiVersion: v1
kind: Secret
metadata:
  name: tekton-ssh-key
  annotations:
    tekton.dev/git-0: test.gjq.com
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: LS0tLS1CRUdJTiBPUEVOU1NI.....

Additional Info

  1. logs of the init container step-credential-initializer-qnnhz are shown as below:
invalid value "tekton-ssh-key=test.gjq.com" for flag -ssh-git: exit status 1
Usage of /ko-app/creds-init:
  -alsologtostderr
        log to standard error as well as files
  -basic-docker value
        List of secret=url pairs.
  -basic-git value
        List of secret=url pairs.
  -docker-cfg string
        Docker .dockercfg secret file.
  -docker-config string
        Docker config.json secret file.
  -log_backtrace_at value
        when logging hits line file:N, emit a stack trace
  -log_dir string
        If non-empty, write log files in this directory
  -logtostderr
        log to standard error instead of files
  -ssh-git value
        List of secret=url pairs.
  -stderrthreshold value
        logs at or above this threshold go to stderr
  -v value
        log level for V logs
  -vmodule value
        comma-separated list of pattern=N settings for file-filtered logging
  1. container details:
Init Containers:
  step-credential-initializer-qnnhz:
    Container ID:  docker://dd6fe9786a55d1353469790733c8a0cf08e7de32552d44d7b4dce819238cacee
    Image:         gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/creds-init@sha256:c8544b7182b53608f7b71f42c31295d8bf534ceeed14be735977c7e289fd37b7
    Image ID:      docker-pullable://gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/creds-init@sha256:c8544b7182b53608f7b71f42c31295d8bf534ceeed14be735977c7e289fd37b7
    Port:          <none>
    Host Port:     <none>
    Command:
      /ko-app/creds-init
    Args:
      -ssh-git=tekton-ssh-key=test.gjq.com
      -basic-docker=tekton-basic-user-pass-registry=hub.c.163.com
    State:          Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Tue, 24 Sep 2019 14:45:35 +0800
      Finished:     Tue, 24 Sep 2019 14:45:36 +0800
    Ready:          False
    Restart Count:  0
    Environment:
      HOME:  /builder/home
    Mounts:
      /builder/home from home (rw)
      /var/build-secrets/tekton-basic-user-pass-registry from secret-volume-tekton-basic-user-pass-registry-hz5q8 (rw)
      /var/build-secrets/tekton-ssh-key from secret-volume-tekton-ssh-key-5mpj6 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from tekton-git-and-registry-token-lltqh (ro)
      /workspace from workspace (rw)
  1. I have tried 'github.com' and 'gitlab.com' , it works well. And I tried another domain called 'gjq.com', it works well too。 So maybe it doesn't support subdomain ?
good first issue help wanted kinbug

Most helpful comment

The reason this error occurred was when ssh-keyscan couldn't reach a server over the internet (fixed by f112277e9). And the reason it appeared as a generic flag error was because we silently swallowed it during flag initialization (fixed by 1caf5bffe).

I'm reasonably confident we can safely consider this issue resolved now. Sorry for the churn!

All 13 comments

/kind bug

Additional Info Again

when I add the "known_hosts" data into my Secret:

apiVersion: v1
kind: Secret
metadata:
  name: tekton-ssh-key
  annotations:
    tekton.dev/git-0: test.gjq.com
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: LS0tLS1CRUdJTiBPUEVOU1NI...
  known_hosts: W2cuaHoubmV0ZWFzZS5jb21dO...

It works !

@gejunqiang thanks for the additional info. creds-init should add the know_hosts, so my guess is, it is not creating the correct one, most likely…

There are some instances where we can't add known_hosts to our YAMLs (I'm looking at you, GitHub...)

@dibyom are you still working on this or can we throw it back in the backlog?

@dibyom We've been hitting by the same error for quite a long time...
We are using Github Actions to invoke about 40 TaskRuns on each PR to perform build/test.
Some of them (randomly?) failing on credential-initializer container with following error in logs:

invalid value "tekton-github-ssh=github.com" for flag -ssh-git: exit status 1
Usage of /ko-app/creds-init:
  -basic-docker value
        List of secret=url pairs.
  -basic-git value
        List of secret=url pairs.
  -docker-cfg string
        Docker .dockercfg secret file.
  -docker-config string
        Docker config.json secret file.
  -ssh-git value
        List of secret=url pairs.

For past 4 weeks there were at least 50 TaskRuns failed with the same issue.
Currently we running tekton-pipelines:v0.10.1 on GKE 1.15.9-gke.26
Any advise on how to debug this issue further would be highly appreciated.

Hi, I was also facing this issue. We have a corporate github instance and this is reproducible whenever my VPN connection is not available. Maybe this info helps!

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

The reason this error occurred was when ssh-keyscan couldn't reach a server over the internet (fixed by f112277e9). And the reason it appeared as a generic flag error was because we silently swallowed it during flag initialization (fixed by 1caf5bffe).

I'm reasonably confident we can safely consider this issue resolved now. Sorry for the churn!

Was this page helpful?
0 / 5 - 0 ratings