RoboStack / RoboStack/robostack.github.io
Add nightly CI for running existing rattler-build tests on build packages
Nobody has claimed this yet.
- Dominant language
- Astro
- Stars
- 385
- Forks
- 36
- Avg merge
- 5h 37m
- Merged PRs (30d)
- 18
Description
Since the migration to rattler-build/recipe v1, and adding tests in vinca, we are now bundling tests with packages itself, so it should be possible not only to run them while a package is built, but also post-deployment after the package was uploaded (see https://rattler.build/latest/testing/). This would permit to easily catch ABI regression such as https://github.com/RoboStack/ros-humble/issues/274 .
The basic logic could be something:
- Check which packages actually have tests (not sure if we can get this info from the conda channel directly, or we need to check https://github.com/RoboStack/ros-noetic/tree/main/tests, https://github.com/RoboStack/ros-humble/tree/main/tests and https://github.com/RoboStack/ros-jazzy/tree/main/tests .
- Download those packages, and run tests on them (not sure if
rattler-build testhas some facility for that). As part of this, we should make sure that the dependencies used are the latest one, and not some kind of locked dependencies - If CI does not pass, report it somewhere (the default reporting logic in GitHub Actions is not really convenient, see https://github.com/orgs/community/discussions/43415
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the rattler-build testing documentation and the existing test directories in ros-noetic, ros-humble, and ros-jazzy. Determine how to identify packages with tests, download them with current dependencies, run the post-deployment tests, and report failures. Done means a nightly workflow performs these checks and exposes failures clearly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100