search

siemens / kas

Setup tool for bitbake based projects
MIT License
363 stars 147 forks source link

Add support for cloning private repos via SSH #23

Closed TheComet closed 3 years ago

TheComet commented 3 years ago

In the case where layers (and bitbake dependencies of layers) need to be cloned from private repos, it is necessary to use more than a single SSH key (in our case, one for each repo).

This change does two things. 1) A new optional property "ssh-key" can be set on each repo in the config file, which is a path that points to a private key file. Git repos will then be able to use that private key to clone from the respective repository by setting GIT_SSH_COMMAND. I have not found any easier way to do this unfortunately. 2) In order for bitbake to be able to clone from private repos, kas now also writes a .ssh/config file in the temporary new home directory using the new section "ssh-config" in the kas config file.

TheComet commented 3 years ago

If this is something you want to have merged into kas, I can update the documentation and bump the schema version number

henning-schild commented 3 years ago

This project does not use issues and PRs. Instead you should send your patches and other requests to the mailinglist.

kas-docker has a switch --ssh-dir which allows passing complex ssh configuration to kas in the form of a full directory which can contain i.e. known_hosts and config. (https://linux.die.net/man/5/ssh_config) That should allow you setting "IdentityFile" per "Host". If multiple of your repos reside on the same "Host" that might not be enough. But there you could in fact work with "Host" and "Hostname" to establish aliases, and your SRC_URIs would use the respective aliases.

Note that there was a recent discussion on the ML where we found that the ssh key can be passed by value and by reference to a file. And kas wants to support both, even if the docs only mention one use-case so far. The discussion has not resulted in actual patches being merged.

I am not sure kas should handle that complexity, maybe having one deployment key across all repos (on the same host) might be the better idea. Also looking at other cases where you clone that code and might want to avoid complexity.

jan-kiszka commented 3 years ago

Thanks for proposing your feature already in form of a patch! As Henning said, we are happy to follow up with a discussion on the ML.

One note in advance when framing commits: "One topic, one commit" is a golden rule, not only here. Your commit contains at least two - if not more - aspects in one, and that is not recommended, see also https://github.com/siemens/kas/blob/master/CONTRIBUTING.md

jan-kiszka commented 3 years ago

Please follow-up on the list with your topic, closing here.