Prep for kilted

[aaronchongth]

What's new

• image building for jazzy has additional step to build and install orphaned alert messages
• api server conditionally imports the alert related messages from the orphaned rmf_alert_msgs if using jazzy, otherwise the usual rmf_task_msgs
• more reusable image build for kilted and rolling
• retarget latest as rolling
• updated docs

Self-checks

• I'm familiar with and follow this Typescript guideline
• I added unit-tests for new components
• I tried testing edge cases
• I tested the behavior of the components that interact with the backend, with an e2e test

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.10%. Comparing base (ea43420) to head (d3327d6).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1060   +/-   ##
=======================================
  Coverage   70.09%   70.10%           
=======================================
  Files         288      288           
  Lines       14175    14175           
  Branches     1136     1137    +1     
=======================================
+ Hits         9936     9937    +1     
+ Misses       4215     4214    -1     
  Partials       24       24           

Flag	Coverage Δ
api-server	79.83% <ø> (+0.03%)	⬆️
rmf-dashboard-framework	67.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[koonpeng]

This appears to be the reason why jazzy has it's own dockerfile. This indicates that the api-server is not compatible with jazzy anymore and building with a newer distro is not a solution.

The proper solution is to support both jazzy and the new Alert messages by using conditional imports.

[aaronchongth]

Since the migration to Jazzy it has already not been compatible in the sense of debian packages, but the API server has never been compatible, we are already using pip to install dependencies on a virtual environment. Since our past decision about releasing the API server (or the lack of ability) onto the buildfarm or pypi, we will be relying on docker images instead, hence rmf_deployment_template

The alerts are used for implementing crucial features of the API server and dashboard, I'd rather keep the feature alive with this caveat instead of rolling a feature back. If a user intends to deploy the API server, only an underlay image is required. At the end of the day, the requirement of using released binaries on any given ROS 2 distro, is to enable release on the buildfarm, which we will not be achieving any time soon without a total re-write.

[koonpeng]

The problem is not that we are using packages outside of the distro (pip), it is that we are using non-jazzy rmf packages to interface with jazzy rmf. If there is a breaking change in a rmf message, then there is no longer a commit that we can build off of.

We don't need to remove any of the alert features, we just need to detect if we are running under jazzy or newer and conditionally enable it. Or alternatively, remove the Alert api and branch off on a jazzy branch, but then we will need to maintain both branches so I think a conditional import is better.

[aaronchongth]

conditional imports have been added

[koonpeng]

The problem is not that we are using packages outside of the distro (pip), it is that we are using non-jazzy rmf packages to interface with jazzy rmf. If there is a breaking change in a rmf message, then there is no longer a commit that we can build off of.

We don't need to remove any of the alert features, we just need to detect if we are running under jazzy or newer and conditionally enable it. Or alternatively, remove the Alert api and branch off on a jazzy branch, but then we will need to maintain both branches so I think a conditional import is better.

[koonpeng]

These alert messages does not seem to be part of rmf-jazzy release, so we cannot use them in a jazzy release.

[koonpeng]

For the jazzy branch, we cannot import messages not part of jazzy release. What I would recommend is to refactor out all the alert subscriptions to another file and create a jazzy version of that file that does not do anything. So we would have

alert_gateway.py
alert_gateway_stub.py

alert_gateway_stub.py would just be a stub that does not do anything. Then on the main gateway, do a conditional import for either one of them depending on the env. For pyright to work, we may also need to add a if TYPE_CHECKING: conditional import to tell it to use the stub. pyright may still complain errors in the jazzy CI so we may need to exclude the file as well (only in jazzy CI).

[aaronchongth]

Closing with #1066