ejgallego
commented
3 years ago I guess even a manual reporting process would be a marked improvement over the current situation, a bit of brainstorming on the implementation:
- warning checking could be a special CI run, once a week, as it may be a bit expensive for the bot in terms of requests?
- the bot could try to check open issues in the projects , and parse the first line to see if an issue has been reported
- we may need better metadata for the CI projects, this was planned since the beginning of CI
- could work better for the both to store a duplicated-free warning log in machine readable format as an artifact?
Following the discussion in today's call: https://github.com/coq/coq/wiki/Coq-Call-2021-10-13
We could report the list of warnings in the GitLab trace in the GitHub Checks tab (with a neutral status if only warnings were raised---though this would make allowed failures less visible, so maybe that's not ideal).
We could also automatically post issues in GitHub repositories of tested projects for new classes of warnings that appear in our CI (though we should think of how we would know which warnings are new and which ones are already known...). Another solution is to manually disable them (by name) in our CI, have coqbot report (in the GitHub Checks tab) when new warnings appear and manually open issues about these...