Hi all, We have discussed many times with Richard on Slack mainly around this topic. But I wanted to discuss it over here and have some brainstorming.
We have had BOM files for quite a while. To avoid the pain to update and maintain them, David created a script to generate them. All good. The problem comes when one is updating or adding or removing a dependency. And I must apologize because it happened to me pretty much every single time. Richard has been looking after the build and fixing my garbage by generating again the BOM files to commit them. Thanks for that. We discussed an approach to generate them in the build so Jenkins is always happy. It works but it has bigger side effects in my opinion. 1/ Jenkins does not commit and then it does not fix my garbage 2/ the snapshots the user uses don't reflect what the CI is testing which deserves the purpose. 3/ the mess is hidden and when cutting the release there is a risk for the BOM files to not be up to date I think we should revert this and at least let the build to fail so we can fix it and maintain the BOM files. I have also investigated Github actions. We could also create a couple of Github actions - to generate the BOM files AND commit them to git if they changed. So they are always up to date and the CI system runs on what the user is using - check file headers to make sure they have ASLv2 header. This is a common error and CI will fail with RAT/checkstyle/PMD in the sanity checks build - do some updates on the website if needed We could start with the BOM and look at the headers. They should be fairly easy to handle and bring some immediate value. What do you think? -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
