The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Firstly, welcome to the community of buildfarmers! You've come to the right place with your question, but if you notice errors or have suggestions for improvement, you're invited to open issues or pull requests directly on https://github.com/ros-infrastructure/buildfarm_deployment or https://github.com/ros-infrastructure/buildfarm_deployment_config. Use the first one if you're not sure where an issue belongs and we'll help guide you to the right place. Your questions help improve the project!
raspberry pi as the repo and another raspberry pi as agent.
Just for background info: the ROS buildfarm doesn't currently support cross-compilation, arm compilation happens inside docker containers with arm-native filesystems that bundle the qemu-user-{arm,aarch64} interpreters so they can be run on AMD64 hosts. I have started playing with native ARM64 support for https://github.com/ros-infrastructure/buildfarm_deployment but it is far from complete or stable. I would be very pleasantly surprised if puppet runs without errors on a Raspberry Pi.
Are you planning to build packages exclusively for Raspberry Pi or are you also hoping to build x86 packages? I think you'll need at least one AMD64 agent to build x86 and x86_64 packages. With qemu you can also use these to build ARM packages.
As for running your repo host on a Raspberry Pi, I can't think of any reason off the top of my head why that won't work, but it hasn't been tested as far as I'm aware.
What operating system are you running on your Pis? Ubuntu Xenial, Raspbian, or something else?
Now let me try to address your individual questions.
I edited these stuffs and changed the jenkins::slave::ui_user and ui_pass to my github username and password which is authorized in my jenkins account.
One thing to watch out for is that the puppet configuration will override your Jenkins auth settings with the following authentication strategy and security realm https://github.com/ros-infrastructure/buildfarm_deployment/blob/2a3d6b409c0e85336ecbcd6e7a3663f913872e27/modules/jenkins_files/files/var/lib/jenkins/config.xml#L8-L12. Running puppet may render you unable to sign in with your GitHub credentials. It's not something that's been tested much. The buildfarm_deployment is designed to be in full control of its jenkins master. If you have other projects using the same Jenkins master you might need to avoid using puppet and try to use it as a guide for setting Jenkins up manually.
The Jenkins agent credentials (referred to as jenkins::slave::ui_user and jenkins::slave::ui_pass in hiera are intended to match the admin username and password hash set in the master.yaml config: https://github.com/ros-infrastructure/buildfarm_deployment_config/blob/3e1dd83cba87099dc925decfe2e26222f52c8dc1/hiera/hieradata/buildfarm_role/master.yaml#L1-L2
You can use a utility like https://github.com/gavanderhoorn/jenkins_bcrypt_pw_util to generate a Jenkins password hash suitable for that line in your config.
Coming to ssh keys, the key specified is the public key I generated using the ssh keygen command in my master machine ?
This is the ssh key that will be used by your jenkins agents to publish packages, documentation, and generated status page html to your repo host. The config used to have an intact keypair but this seemed to me too egregious of a security risk so I replaced the matching keypair with a public key and a suggestion to supply your own key pair. Since the instructions for doing so are not clear I've opened a pull request with additional info here: https://github.com/ros-infrastructure/buildfarm_deployment_config/pull/32 Let me know if the improved comments help and from there I'll enhance the README documentation.
You'll also want to provide a current ssh host key for your repo host to allow your agents to connect to it without manual intervention. This is another step that could do with improved instructions. I use the ed25519 keys when I can because they're short and easy to copy. I've opened an additional PR to improve those instructions (and fix a bug in the default config) https://github.com/ros-infrastructure/buildfarm_deployment_config/pull/33
Then, autoreconfigure is setup to be false in the common.yaml file but it is listed as branch in the documentation. Should I go about changing this ?
For small buildfarm setups, I actually advocate keeping the autoreconfigure script disabled entirely. Hiera configurations are hierarchical so setting it to false in common.yaml can allow it to be overridden in agent.yaml or repo.yaml which are higher in priority in the hiera configuration. autoreconfigure on master can cause problems and so is not currently advised.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
