RoboStack / RoboStack/robostack.github.io
Add nightly CI for running existing rattler-build tests on build packages
Personne n'a encore pris cette issue.
- Langage dominant
- Astro
- Étoiles
- 385
- Forks
- 36
- Merge moyen
- 5 h 37 min
- PR mergées (30 j)
- 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
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par la documentation des tests de rattler-build et les répertoires de tests existants dans ros-noetic, ros-humble et ros-jazzy. Déterminez comment identifier les paquets qui possèdent des tests, les télécharger avec leurs dépendances actuelles, exécuter les tests post-déploiement et signaler les échecs. La tâche sera considérée comme terminée lorsqu’un workflow nocturne effectuera ces vérifications et exposera clairement les échecs.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- github-actions
- Domaine
- ci-cd, testing-qa
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100