import_upstream job failing on custom build server

[Tom Moore]

Hello all,

I'm attempting to put together a custom build server and have gotten to the point where I am attempting to run the admin jobs. Right now, the trouble I'm having is that the import_upstream job reports success, but upon investigation, I see this output for building, testing, and main:

...
17:13:41 aptmethod got 'http://repos.ros.org/repos/ros_bootstrap/pool/main/s/sdformat2/sdformat-sdf_2.3.2-1~trusty_all.deb'
17:13:41 aptmethod got 'http://repos.ros.org/repos/ros_bootstrap/pool/main/s/sixad/sixad_1.6.1~trusty1_amd64.deb'
17:13:42 gpgme gave error GPGME:11:  Bad passphrase
17:13:42 ERROR: Could not finish exporting 'trusty'!
17:13:42 This means that from outside your repository will still look like before (and
17:13:42 should still work if this old state worked), but the changes intended with this
17:13:42 call will not be visible until you call export directly (via reprepro export)
17:13:42 Changes will also get visible when something else changes the same file and
17:13:42 thus creates a new export of that file, but even changes to other parts of the
17:13:42 same distribution will not!
17:13:42 There have been errors!

It appears I have a bad passphrase for one of the keys in the buildfarm_deployment_config. However, the passphrase I am using for the credentials::jenkins-slave::passphrase is the correct phrase, and I retrieved its hashed value from /var/lib/jenkins/credentials.xml for a local instance that I spun up. I'm almost certainly missing something, but doing a search for the gpgme error yields (as it would) some results wherein users are experiencing very similar issues.
I have yet to try simply using a key with an empty passphrase and going with the default values in the buildfarm_deployment_config, but I wanted to see if anyone else had a similar issue previously.

Thanks!

-Tom

[Tom Moore]

Update: I tried manually running the import_upstream jobs directly. I changed the command 

reprepro -v -b /var/repos/ubuntu/building --noskipold update trusty

to

reprepro -VV --ask-passphrase -b /var/repos/ubuntu/building --noskipold update trusty

The --ask-passphrase command does as requested and asks me to enter the passphrase for the GPG key. When it has created the files in question, it exits successfully.

So the question becomes why is this necessary? Is there a configuration step I missed that would allow reprepro to create the files in question without needing a passphrase for the GPG key?

[Tully Foote]

Hi Tom, 

The passphrase in `credential::jenkins-slave::passphrase` is for the ssh credentials. The passphrase you need to interact with reprepro is the GPG passphrase. We have not tested with a GPG key requiring a passphrase. The gpg key is stored locally on the repository machine and could probably be unlocked in the keyring manually at boot and persist for the duration of the uptime of the repository machine. (Which should be pretty high) 

It would be great if you could find a way to forward the gpg passphrase from jenkins to the repository. It looks like there's a few plugins that might help: https://stackoverflow.com/questions/4947187/how-to-configure-jenkins-hudson-with-gpg-signature Though it's not going to be as easy as using an ssh agent. Though there are some solutions that might be possible to make work: https://superuser.com/questions/161973/how-can-i-forward-a-gpg-key-via-ssh-agent https://serverfault.com/questions/562414/using-gpg-agent-over-ssh 

Tully

--
You received this message because you are subscribed to the Google Groups "ros-sig-buildfarm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildf...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-buildfarm/11a8d30f-9498-453b-ae03-52cbd846b4cc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tom Moore]

Thanks, Tully. I'll check out those links and see what I can do.