Oh... i did miss the asf-site thing, David mentioned. So my proposal is not useful ;)
Am Mittwoch, dem 09.02.2022 um 14:32 +0000 schrieb Zowalla, Richard: > 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 > > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar) mail: [email protected] web: https://www.mi.hs-heilbronn.de/
smime.p7s
Description: S/MIME cryptographic signature
