Hi, Our GitHub Actions already do the Style/RAT checks.
ASF Infra also have some concerns regarding GitHub actions [1] and discussed it on [email protected] multiple times. However, Jenkins is capable of committing changes (we do it for the generated tomee site) - so perhaps it could also be done for the main repo? We could set up an additional job, which is triggered after a commit, which (1) checks out the project (2) do a quick build w/o tests (3) generate the boms (4) commit and push if there is a change (we do sth similar with the tomee site every 12h) Then we setup the subsequent jobs (quick, full) to trigger only after a successful "bom generation job". Wouldn't that work? Gruß Richard [1] https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status Am Mittwoch, dem 09.02.2022 um 09:15 -0500 schrieb David Blevins: > The trick is that Apache doesn’t have any bot accounts that we could > use to > do commits to master. So there really isn’t any way to use Jenkins, > GitHub > Actions, etc. > > The limited functionality Apache does have for committing files is > for > website generation, but it is setup to only work for branches called > “asf-site” (or something like that) and works from only one specific > Jenkins node. > > The best we could do is create a bot that made a PR one of us had to > merge > and/or get this to be done in the build and we ensure we remember to > commit > it. (We could potentially do both so there is a convenient backup if > we > forget to do the commit ourselves before we push). > > -David > > On Wed, Feb 9, 2022 at 8:51 AM Jean-Louis Monteiro < > [email protected]> > wrote: > > > 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 > >
smime.p7s
Description: S/MIME cryptographic signature
