Closed fmauch closed 6 months ago
What I'm wondering about: If a downstream test is flaky, we will get a new issue every day?
can we check if an issue exists already, for example "Test failure for webots"? Like dependabot is not posting duplicates.
Maybe we can additionally look for bots (or program one), which can be activated from every PR (@ros2controlbot test downstream
), as one can trigger mergify.
What I'm wondering about: If a downstream test is flaky, we will get a new issue every day?
No, it shouldn't. With the update_existing: true
flag I set there should only be one (open) issue with the same title that will get updated. In my point of view downstream packages with flaky tests would disqualify as being run inside ros2_control's CI.
* can we parse from ICI, which package failed in which state?
Not that I know of. This would be nice but I'm afraid one would have to inspect the build which is why I added the job link to the issue.
* can we check if an issue exists already, for example "Test failure for webots"? Like dependabot is not posting duplicates.
As stated above that should work already, however it will check for example for "CI build job rolling/main failed!" and update that.
Maybe we can additionally look for bots (or program one), which can be activated from every PR (
@ros2controlbot test downstream
), as one can trigger mergify.
That sounds nice. One possibility might be https://github.com/GregaVrbancic/gh-workflow-bot but that looks rather unmaintained. I think in the scope of this PR that might be over the top, we could keep that in mind for later, would you agree?
I agree to all of your points.
ICI has exit codes which can be parsed: https://github.com/ros-industrial/industrial_ci/pull/755 But it is not documented and not 100% clear for me how to use them
at least the test step can be parsed as
test "${{ steps.ici.outputs.target_test_results}}" = "0" || exit 1
see their CI
otherwise we would have to write an own js wrapper around their script and parse the text output..
This should add an issue like this when the ICI fails in a scheduled build.
See workflow run here, where I artificially introduced a build error.
The issues data could be modified (title, labels, description...) but I would need input for that.