New release?

[tonybaltovski]

We've been using 3.0.0 up till now but since ros-infrastructure/bloom#649 was merged, it fails. Could a new release be tagged please?

[cottsay]

We do need to get a release of this package out the door, without question.

That said, the bloom change shouldn't change any behavior unless nocheck is supplied to debbuild. Can you please give us some more information about the failure mode?

[tonybaltovski]

It is being applied for <test_depend> and then ros_buildfarm is trying to use PACKAGE_NAME <!nocheck> as shown below for roslint:

11:55:56   File "/usr/lib/python3/dist-packages/apt/cache.py", line 299, in __getitem__
11:55:56     rawpkg = self._cache[key]
11:55:56 KeyError: 'ros-noetic-roslint <!nocheck>'
11:55:56 
11:55:56 During handling of the above exception, another exception occurred:
11:55:56 
11:55:56 Traceback (most recent call last):
11:55:56   File "/tmp/ros_buildfarm/scripts/release/create_binarydeb_task_generator.py", line 166, in <module>
11:55:56     main()
11:55:56   File "/tmp/ros_buildfarm/scripts/release/create_binarydeb_task_generator.py", line 84, in main
11:55:56     debian_pkg_versions = get_binary_package_versions(
11:55:56   File "/tmp/ros_buildfarm/ros_buildfarm/common.py", line 144, in get_binary_package_versions
11:55:56     pkg = apt_cache[debian_pkg_name]
11:55:56   File "/usr/lib/python3/dist-packages/apt/cache.py", line 301, in __getitem__
11:55:56     raise KeyError('The cache has no package named %r' % key)
11:55:56 KeyError: "The cache has no package named 'ros-noetic-roslint <!nocheck>'"
11:55:56 Build step 'Execute shell' marked build as failure

[cottsay]

Drat. That's my fault. I think this is the missing change: #919

@nuclearsandwich, how would you feel about making a 3.x branch and cherry-picking this change to release a 3.0.1?

[nuclearsandwich]

@nuclearsandwich, how would you feel about making a 3.x branch and cherry-picking this change to release a 3.0.1?

I think that's a good way to go about it. We'll not be "supporting" the 3.x branch in all likelihood but we should at least not break existing behavior.

[tonybaltovski]

Should we just switch to using master? Asking since it there will be no support.

[nuclearsandwich]

Should we just switch to using master? Asking since it there will be no support.

A TODO for me will be to take this answer and put it in documentation.

If you objective is to replicate the behavior of the official build farms at build.ros.org and build.ros2.org, then you should use the primary development branch, currently master. If you're running on an older Xenial based buildfarm_deployment then master may no longer work for you and you'll need to stick with 3.x

Both @cottsay and I want to get ros_buildfarm onto a more regular release cadence so that it's easier for community users to rely on stable releases but it's unlikely that we'll ever want the official buildfarm to stop tracking HEAD. What I'd personally like to do is be able to have a support matrix that includes Jenkins versions, cookbook-ros-buildfarm versions, and ros_buildfarm versions so that the tested combinations are easier to review.

[ijnek]

Just as an FYI, following the Setup environment to deploy configuration #virtualenv instructions, the command generate_release_script.py fails with version 3.0.0 if PyYaml is >=6.0.0 because yaml.load() always requires a Loader arg. (Release Notes). +1 on making a release if possible.