Working with private repos

[jeffochoa]

Can't make it work with a private repository

Failed to clone the git@bitbucket.org:.....git repository, try running in interactive mode so that you can enter your Bitbucket OAuth consumer credentials

Is there a way to share my local ssh credentials with the docker container?

[ktomk]

Please try the --ssh switch from #6 .

[jeffochoa]

Thanks @ktomk, I tried but it didn't work.

I'm using Mac, I wonder if has something to do with the SSH_AUTH_SOCK variable 🤔 Any idea?

[ktomk]

I'd say it depends. SSH_AUTH_SOCK should be available on Mac as well, it is the SSH agent.

However this might be a different issue. --ssh is to share your ssh credentials with the ssh-agent, when you clone, which authentication is in use? From your report I can see it is a bitbucket.org repository and it looks like it is using ssh.

You may try with a test-pipeline (similar as in #6) if it works that way with bitbucket:

$ mkdir -p ~/empty-directory-pipelines-test
$ cd ~/empty-directory-pipelines-test
$ <<'PIPELINE' bin/pipelines --file - --verbatim --ssh
pipelines:
  default:
    - step:
        image: ktomk/pipelines:ssh
        script:
          - mkdir -p -m 0600 ~/.ssh && ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts
          - ssh -T git@bitbucket.org || test $? -eq 1
PIPELINE

with this example I get the authentication to run:

+ mkdir -p -m 0600 ~/.ssh && ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts
# bitbucket.org:22 SSH-2.0-conker_c123b90d72-dirty conker-3004
# bitbucket.org:22 SSH-2.0-conker_c123b90d72-dirty conker-3003
# bitbucket.org:22 SSH-2.0-conker_c123b90d72-dirty conker-3001
# bitbucket.org:22 SSH-2.0-conker_c123b90d72-dirty conker-3005
# bitbucket.org:22 SSH-2.0-conker_c123b90d72-dirty conker-3006

+ ssh -T git@bitbucket.org || test $? -eq 1
Warning: Permanently added the RSA host key for IP address '104.192.141.1' to the list of known hosts.
logged in as ktomk

You can use git or hg to connect to Bitbucket. Shell access is disabled

which looks good so far as the authentication worked (and that shell access is disabled is fine, too).

please check if that example works for you. probably this is related to known hosts, we could see then how to give this a better accessibility/usability.

it would also help to have a better example at hand so that the issue becomes better reproducible. that is always helpful.

/Edit: The test is done best from within an empty directory. Before a full run and next to verbatim there is also the --no-run and the --dry-run switch.

[ktomk]

The test instructions might have been incomplete and risk to copy large amounts of data into the test-container. I've edited my last comment accordingly and left a hint on the --no-run and --dry-run switch.

Also in a recent test in #6 a user could confirm --ssh is currently not working on macos. We're looking into it, however if you can confirm this is also useful information as I do not have a macos to test at hand.