Inject Netrc and SSH keys to clone private repositories

[dennybaa]

Is there any necessity to do so?

I was struggling with this for half-of day :) And yeah I found it, but overwriting the user's data might seem to be not the best solution.

Btw what's the purpose id_rsa which can be found in runner container?

[bradrydzewski]

this is required in order to clone private repositories, including the ability to go get, npm install, etc private repositories.

[dennybaa]

That's what I've thought, but it's not the way to rewrite it. There are options like ssh wrappers for example. Why not to let drone keep specific ssh files also in /var, same as with sources?

[dennybaa]

Well I haven't seen this things documented( Or I might be just wrong, anyway it would be nice if it's described or better control has given to the user.

Am I right these private keys correspond to those public in repo settings? If so it seems unhandy because user will have to publish these pubkeys into his vcs. But drone can do it automatically in case of github :) Wrapper is a cleaner approach anyway... It could be improvement then.

[bradrydzewski]

Am I right these private keys correspond to those public in repo settings? If so it seems unhandy because user will have to publish these pubkeys into his vcs. But drone can do it automatically in case of github

Drone automatically uploads the key for GitHub, GitLab, Gogs, Bitbucket and Stash. This covers the most popular use cases.

wrapper is a cleaner approach anyway

My concern with GIT_SSH is that it may not work with all dependency management solutions. Early versions of npm install didn't support GIT_SSH, for example, which is why we didn't use it. I'd hate to break Drone for an entire language or ecosystem. Is there some way to avoid this?

[dennybaa]

Drone automatically uploads the key for GitHub, GitLab, Gogs, Bitbucket and Stash. This covers the most popular use cases.

It's an awesome feature indeed.

My concern with GIT_SSH is that it may not work with all dependency management solutions. Early versions of npm install didn't support GIT_SSH, for example, which is why we didn't use it. I'd hate to break Drone for an entire language or ecosystem. Is there some way to avoid this?

Yeap, I totally agree GIT_SSH approach doesn't scale with different tools (such as mentioned old versions of npm). I'm starting to think the drone's approach is the optimal so far.

But again, I would suggest maybe to implement key selection, it would eliminate user's misunderstanding. For example there might be option such as:
private key /root/.ssh/id_rsa:

1. Use drone automatic key
2. Provide manual key

In case key exists do not overwrite (same with config) when the first way is chosen but this should be logged into the build session. I don't know maybe I'm overcomplicating when I say that it would be a nice thing), because implementation of all these can be tricky...

[bradrydzewski]

@dennybaa the good news is in 0.4 (upcoming release) we try to use git+https and a netrc with the oauth token to clone a repository. This is supported by GitHub and Bitbucket at the moment, and I am hopeful others will follow suit.

This means we may be able to omit the ssh keys all together (for GitHub and Bitbucket at least). Let's see how things work out with 0.4, and if that solves the issue or not. If not, I'm sure we can make it configurable as you suggested

[dennybaa]

@bradrydzewski, this is the great news.

This means we may be able to omit the ssh keys all together (for GitHub at least). Let's see how things work out with 0.4, and if that solves the issue or not. If not, I'm sure we can make it configurable as you suggested

If we omit injection of keys, it might be a bad practice. User might want tooling especially when it touches deployment (ex. capistrano). Nobody wants to keep secure keys inside repository :) and in this case manual injection makes real sense.

[axel22]

+1

Would be very useful indeed to be able to inject an ssh key into the build. Much of our previous CI relies on modifying separate Git repositories after a successful build.

[bradrydzewski]

@axel22 an ssh key is injected into the build container if the repository is private. Furthermore, ssh keys are provided to plugins (such as the git_push plugin) for both pubic and private repos in order to push code at the end of a completed build. So everything you need should be there.

[axel22]

It is true that providing ssh keys to plugins can solve the issue.
However, in our case, existing project setups (previously used in Jenkins, specifically) assume that there is an .ssh key pair available during the entire build - our build tool does some pushes to other Git repositories after the tests pass. It is theoretically possible to move that functionality to plugins, but it would require extra work for us - it is more likely that we would manually hack a solution which makes the keys available in Drone during non-pull-request builds.

Hope I'm not being too pushy, just giving some feedback :)

[bradrydzewski]

@axel22 are your repos public or private? The ssh key is automatically injected into the repository if private

[axel22]

@bradrydzewski Most of our repos are public.

[axel22]

@bradrydzewski
Just FYI - I think that a combination of:

• keeping the password-protected ssh key in a custom build image
• using ssh-agent in the build image
• putting the ssh key password into secrets
• passing the secret to env vars in .drone.yml
• then calling ssh-add to unlock the private key
• clearing the env vars before the build starts

... solves the problem