[ROS1] Buildfarm PR testing no longer works

Hi, I hope this is the correct place to ask :wink:

I noticed that pull requests are no longer tested by the ROS1 buildfarm for several of the packages I maintain (GitHub - AIS-Bonn/catch_ros: ROS wrapper for the Catch unit test framework, GitHub - AIS-Bonn/nimbro_network: ROS network stack: Topic/service transport over unreliable network c). I’m not sure how to debug this further, but I’m reasonably sure everything is still setup correctly according to the Wiki (buildfarm/Pull request testing - ROS Wiki).

Here’s a link to a relevant Jenkins job: Npr__catch_ros__ubuntu_focal_amd64 [Jenkins]
And here’s a PR which the buildfarm doesn’t pick up: Update Catch to version v2.13.7 by shr-project · Pull Request #15 · AIS-Bonn/catch_ros · GitHub

PR testing used to work fine on both mentioned repositories.

Hi @xqms, we recently created the osrf/infrastructure repository for reporting issues. I’ll take a look at this now and if it’s not an immediately resolveable problem I’ll ask you to create an issue there and we’ll continue the conversation there.

I just checked and I agree the configuration does look sound and correct. I’m going to try triggering another retest while watching the Jenkins logs…

[Update] and instantly see a 401 Unauthorized in the logs. So something is misbehaving with the Jenkins pull request builder token. Secret text credentials are not being updated when changed. · Issue #98 · ros-infrastructure/cookbook-ros-buildfarm · GitHub is a factor but I had manually updated tokens in production once the issue was identified.

Follow-up update. Although the token is authenticating properly in the test console it seems as though the actual webhook thread is holding on to an invalid token and I’m waiting for the farm to become idle in order to do a restart of the Jenkins server to confirm that hypothesis.

This issue was resolved with a restart of the Jenkins instance after confirming the previously deployed token was not being used in production.

Thanks for the quick response & fix, @nuclearsandwich! I’ll keep the infrastructure repo in mind for such issues, thanks for the link.