Add article on checking package build status to Releasing guide. #4621
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kscottz
reviewed
Aug 20, 2024
| @@ -0,0 +1,45 @@ | |||
| Check package build status | |||
There was a problem hiding this comment.
Suggested change
| Check package build status | |
| Check package build status on the Build Farm |
God, we need a style guide. Is it Build Farm or Buildfarm or build farm?!
| Email notifications | ||
| ------------------- | ||
|
|
||
| Maintainers of a released package will receive email notifications from the ROS 2 build farm, specifically ``noreply@build.ros2.org`` when builds fail or succeed after failure. |
There was a problem hiding this comment.
What is this e-mail keyed to? The package.xml I presume?
It would be good to remind people where that address is set. Can more than one person be notified?
| Check package build status | ||
| ========================== | ||
|
|
||
| Released ROS 2 packages with binary releases enabled are built on the `ROS 2 build farm <https://build.ros2.org>`_. |
There was a problem hiding this comment.
Suggested change
| Released ROS 2 packages with binary releases enabled are built on the `ROS 2 build farm <https://build.ros2.org>`_. | |
| The ROS 2 build farm is the ROS project's primary means of generating binary packages from publicly available ROS package source code repositories. Released ROS 2 packages with the `binary releases` flag enabled are built on the `ROS 2 build farm <https://build.ros2.org>`_ and then made available to downstream users via a variety of different package management systems (e.g. Yum, Apt, RPM, etc) . |
Drawing this out for the less versed users.
| --------------------------------- | ||
|
|
||
| The ROS 2 build farm web interface was not designed for the scale of jobs on the build farm. | ||
| Navigating to specific builds using the web interface is cumbersome and generates unnecessary load and thus is not recommended. |
There was a problem hiding this comment.
Suggested change
| Navigating to specific builds using the web interface is cumbersome and generates unnecessary load and thus is not recommended. | |
| Navigating to specific builds using the web interface is cumbersome and generates unnecessary load on the build farm and thus is not recommended. |
| The ROS 2 build farm repository hosts several status pages which are used by the ROS core team and ROS bosses. | ||
| These status pages can be used by package maintainers as well. | ||
|
|
||
| ROS 2 status pages are hosted at `<https://repo.ros2.org/status_page>`_, which contains an autoindex of all current status pages. |
There was a problem hiding this comment.
Suggested change
| ROS 2 status pages are hosted at `<https://repo.ros2.org/status_page>`_, which contains an autoindex of all current status pages. | |
| ROS 2 status pages are hosted at `<https://repo.ros2.org/status_page>`_, which contains an automatically generated index of all current package status pages. |
| ROS 2 status pages are hosted at `<https://repo.ros2.org/status_page>`_, which contains an autoindex of all current status pages. | ||
| The status pages which are most relevant to package maintainers are the "release status" pages which are named ``ros_${ROS_DISTRO}_${TARGET}.html``. | ||
| The ``${ROS_DISTRO}`` value is the codename of a specific ROS distribution and the ``${TARGET}`` value is taken from the specific release build configuration file in the `ROS 2 build farm configuration <https://github.com/ros2/ros_buildfarm_config>`_. | ||
| Current target values are |
There was a problem hiding this comment.
Suggested change
| Current target values are | |
| Current target values are: |
| - ``XYv8`` for the ARM64 Ubuntu release supported by the ROS distribution. | ||
| The first two characters indicate the operating system distribution (``u`` for Ubuntu, ``d`` for Debian) and release codename (e.g. ``j`` for Ubuntu 22.04 Jammy, ``n`` for Ubuntu 24.04 Noble), the latter two characters ``v8`` refer to the target architecture ARM64 by its historic Debian designation ``armv8``. | ||
|
|
||
|
|
There was a problem hiding this comment.
Suggested change
| For example, if you wish to find the status page for ROS 2 Jazzy packages built for the Ubuntu 24.04 Noble operating system on an Arm64 architecture your ``${ROS_DISTRO}`` would be `jazzy` and your ``${TARGET}`` would be ``unv8``, yielding the URL: ``https://repo.ros2.org/status_page/ros_jazzy_unv8.html`` |
| TODO(nuclearsandwich) this is just filler to prove images work. | ||
| Needs elaboration | ||
|
|
||
| .. image:: Check-package-build-status/images/fixed_package.png |
There was a problem hiding this comment.
Honestly, I think a diagram here may be easier to read here than displaying the images and then trying to describe what's going on. Is it easy to maintain, not really, but it is a lot clearer.
If I had a better idea about what is going on I could whip something up in Canva really quick. What are you doing this Friday at 11am? =)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checking package status on the build farm is not as straightforward now that navigating the Jenkins UI is almost prohibitively cumbersome.
Email notifications are the expected default mechanism for maintainers to keep up with package build status, but the status pages provide the most direct route to finding your package in the build farm UI without knowledge of our Jenkins organization.
This is a piece of #4617.