Autoware: 1.4.0-1 in 'kinetic/distribution.yaml' [bloom]

[dejanpan]

Increasing version of package(s) in repository Autoware to 1.4.0-1:

• upstream repository: https://github.com/CPFL/Autoware.git
• release repository: https://github.com/CPFL/Autoware-release.git
• distro file: kinetic/distribution.yaml
• bloom version: 0.5.26
• previous version for package: null

autoware_msgs

• No changes

[dejanpan]

This PR should now be OK.
Can someone maybe tell me where can I now follow the progress after this PR will be merged?
I mean the jenkins build on the buildfarm itself and moving of pkg from building, testing and main?

[dirk-thomas]

Once the PR has been merged the corresponding jobs are generated. They will be triggered automatically shortly afterwards. You can find them on build.ros.org (by searching) or if you create a wiki page for autoware_msgs with the package template (they are linked in the side bar).

If the release builds succeed and the farm finishes rebuilding all packages of a specific ROS distro and architecture the Debian package becomes automatically available in the testing repo (assuming no major regressions). The sync to the main repo is a manual step and is announced on discourse. You can see the status on e.g. this page: http://repositories.ros.org/status_page/ros_kinetic_default.html

[mikaelarguedas]

Once this is merged a set of jobs will be created on the buildfarm. If any job fail an email will be sent to the maintainer listed in the package.xml. Once the jobs are created the package will be listed in the kinetic status pages (the ones starting with "ros_kinetic"). each platform will have 3 boxes, indicating the status and version of the package in respectively the building, testing and main repository. The left box is a link to the corresponding job on the buildfarm.

[dejanpan]

you guys are awesome, thx.

[dejanpan]

Gents, I have one more Q. I need to release 90 more pkgs in https://github.com/dejanpan/Autoware.
Most of the pkgs have CMakeLists.txt and package.xml files that need to be mightily fixed wrt system dependencies and dependencies on other ROS packages. How can I best locally test such that packages will build on the buildfarm later on?

I looked over https://roscon.ros.org/2016/presentations/ROSCon2016%20Build%20Farm.pdf and it seems that i have 3 options:
a) every time I fix new package I start from a fresh vagrant instance
b) catkin_make_isolated
c) Run "Jobs" Locally

With b) and c) I am not very familial. What would you suggest?

[mikaelarguedas]

catkin_make_isolated is similar to catkin_make except that each package is built in a different cmake context. It will help you identify some problems like relying on headers find_packaged by another package in your workspace etc. Though it will not help you fix missing dependencies in your package.xml.

For example autoware_msgs calls find_package on sensor_msgs but doesnt list it in the package.xml.
If you build with catkin_make or catkin_make_isolated, it will work because very likely you have sensor_msgs installed on your machine. That's where "running the jobs locally" is useful.

The easiest way to do this is to use the prerelease website.
It allows you to select any repository listed in rosdistro and generate jobs to build them.
In your case you would go to prerelease.ros.org/kinetic select the "Autoware" repository and select the 1.4.0 version. Then after clicking next a few times the website will give a command to run in your terminal to create and launch the jobs. The jobs will run in docker containers so will not impact your system and will not have any dependency installed except the ones listed in your package.xml. You can then adapt you package.xml and rerun the job until it passes. Once it passes you're ready to make a new release.

[dejanpan]

I ran as you suggested and then the `prerelease.sh` got stuck (since about 1h) on: ``` tep 19 : RUN echo "2017-08-05 17:07:24 -0800" ---> Running in e174fa080516 2017-08-05 17:07:24 -0800 ---> ae0d933d8c99 Removing intermediate container e174fa080516 Step 20 : RUN python3 -u /tmp/wrapper_scripts/apt.py update ---> Running in 6b4ab19c3a41 Invoking 'apt-get update' ``` Is this normal? Maybe we should also move this discussion to Discourse buildfarm? D.

…

On Sat, Aug 5, 2017 at 5:36 PM Mikael Arguedas ***@***.***> wrote: catkin_make_isolated is similar to catkin_make except that each package is built in a different cmake context. It will help you identify some problems like relying on headers find_packaged by another package in your workspace etc. Though it will not help you fix missing dependencies in your package.xml. For example autoware_msgs calls find_package on sensor_msgs but doesnt list it in the package.xml. If you build with catkin_make or catkin_make_isolated, it will work because very likely you have sensor_msgs installed on your machine. That's where "running the jobs locally" is useful. The easiest way to do this is to use the prerelease website <http://prerelease.ros.org>. It allows you to select any repository listed in rosdistro and generate jobs to build them. In your case you would go to prerelease.ros.org/kinetic select the "Autoware" repository and select the 1.4.0 version. Then after clicking next a few times the website will give a command to run in your terminal to create and launch the jobs. The jobs will run in docker containers so will not impact your system and will not have any dependency installed except the ones listed in your package.xml. You can then adapt you package.xml and rerun the job until it passes. Once it passes you're ready to make a new release. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15705 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABD4MxxnuNNYE_eNlnE2MaTX7wyARwmks5sVQp7gaJpZM4OulHD> .

[mikaelarguedas]

Is this normal?

hmm no it's not normal it should not hang like if you were running apt-get update on your host os, I don't remember seeing apt update get stuck like this in the past.
I ran the same test earlier today with the branch used for your PR and everything built fine.

Maybe we should also move this discussion to Discourse buildfarm?

Yes please feel free to start a thread with the last few messages on discourse and we can iterate there. Please also try to rerun the prerelease script and see if you can reproduce the error.

[dejanpan]

It was probably just a hiccup, now it works. I configured a pre-release job like this: """ generate_prerelease_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml kinetic default ubuntu xenial amd64 --custom-repo autoware_msgs:git: https://github.com/CPFL/Autoware:develop --level 1 --output-dir ./ --pkg autoware_msgs """ and I expected it to build an autoware_msgs pkg only. However it again tries to build all of the packages and complains about not being able to find package common. D.

…

On Sat, Aug 5, 2017 at 7:57 PM Mikael Arguedas ***@***.***> wrote: Is this normal? hmm no it's not normal it should not hang like if you were running apt-get update on your host os, I don't remember seeing apt update get stuck like this in the past. I ran the same test earlier today with the branch <https://github.com/CPFL/Autoware/tree/fix/autoware-msgs-cmake-766> used for your PR and everything built fine. Maybe we should also move this discussion to Discourse buildfarm? Yes please feel free to start a thread with the last few messages on discourse and we can iterate there. Please also try to rerun the prerelease script and see if you can reproduce the error. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15705 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABD4FHmT25P0QZkjWZ69AzqLA6xlvvwks5sVSt8gaJpZM4OulHD> .

[tfoote]

If you want it to test only the package you passed use --level 0 That argument is the number of layers of recursive dependencies to build. It's likely that all the other packages have a dependency on the specified message package.

[tfoote]

I ran a test build with --level 0 and it appears that it's still trying to resolve the rosdeps and install them even before the build. Talking with @mikaelarguedas I think that the best recommendation we have is to drop CATKIN_IGNORE files into all the other packages on your desired test branch. We don't have other mechanisms to ignore packages when building from source.

[dejanpan]

Tully, that worked perfectly, thx a lot. D.

…

On Mon, Aug 7, 2017 at 11:36 AM Tully Foote ***@***.***> wrote: I ran a test build with --level 0 and it appears that it's still trying to resolve the rosdeps and install them even before the build. Talking with @mikaelarguedas <https://github.com/mikaelarguedas> I think that the best recommendation we have is to drop CATKIN_IGNORE files into all the other packages on your desired test branch. We don't have other mechanisms to ignore packages when building from source. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15705 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABD4CsmRvekc46m_nmCeR6er4UqUgxGks5sV1kZgaJpZM4OulHD> .

[mikaelarguedas]

@dejanpan FYI: autoware_msgs has been failing every build since its release. I'm planning on removing the release section so that this doesnt run on the farm every night. It will be automatically readded by bloom when you'll open a PR with your next release.

@tfoote FYI

[dejanpan]

@mikaelarguedas this is weird. I swear that it built locally when i first released it. and then i guess since i am not listed in the package.xml as maintainer - i didnt get build errors. Super sorry about this. Will fix tomorrow.

[mikaelarguedas]

Sounds good 👍
IIRC our conversation as the time, there were dependency issues in CMake/package.xml that you addressed in autowarefoundation/autoware@a8225f6#diff-9a798297964fb7624af64a79f33186d8 but didnt release waiting for other packages to be ready. Tagging and releasing a version with that fix should fix the job.