You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2022/02/09 13:51:13 UTC
Generated BOM files
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
Re: Generated BOM files
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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 users@infra.a.o 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 <
> > jlmonteiro@tomitribe.com>
> > 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: richard.zowalla@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/
Re: Generated BOM files
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi,
Our GitHub Actions already do the Style/RAT checks.
ASF Infra also have some concerns regarding GitHub actions [1] and
discussed it on users@infra.a.o 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 <
> jlmonteiro@tomitribe.com>
> 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
> >
Re: Generated BOM files
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Thanks for the pointer, David.
I just had a look and pushed an additional step to our config, which is
based on the setup provided by Camel.
Seems to work nicely: https://github.com/apache/tomee/pull/811
Gruß
Richard
Am Mittwoch, dem 09.02.2022 um 07:47 -0800 schrieb David Jencks:
> While GitHub actions shouldn’t be able to commit anything, they can
> create a PR that can then be reviewed and merged by a committer.
> Apache camel uses this to good effect: they have far more complicated
> things than BOMs generated.
>
> David Jencks
>
> Sent from my iPhone
>
> > On Feb 9, 2022, at 6:40 AM, Zowalla, Richard <
> > richard.zowalla@hs-heilbronn.de> wrote:
> >
> > I think, that the inconvience originates from the fact, that one
> > has to
> > conduct a quick build w/o tests after changing a simple version
> > string
> > - even if one does not expect any compile issues and just want to
> > see
> > the impact in a CI/CD environment
> >
> > The current "generate in the build" is tied to "package".
> >
> >
> > > Am Mittwoch, dem 09.02.2022 um 15:33 +0100 schrieb Jean-Louis
> > > Monteiro:
> > > Thanks David for the extra infra information. That makes the
> > > automation a
> > > bit harder indeed.
> > >
> > > Let's keep the "generate in the build" as it is today and see if
> > > we
> > > can
> > > remember to push and when I say we, I mean "I" 😀
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Wed, Feb 9, 2022 at 3:15 PM David Blevins <
> > > dblevins@tomitribe.com>
> > > wrote:
> > >
> > > > 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 <
> > > > jlmonteiro@tomitribe.com>
> > > > 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
> > > > >
> > > > --
> > > > Sent from Gmail Mobile
> > > >
Re: Generated BOM files
Posted by David Jencks <da...@gmail.com>.
While GitHub actions shouldn’t be able to commit anything, they can create a PR that can then be reviewed and merged by a committer. Apache camel uses this to good effect: they have far more complicated things than BOMs generated.
David Jencks
Sent from my iPhone
> On Feb 9, 2022, at 6:40 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> I think, that the inconvience originates from the fact, that one has to
> conduct a quick build w/o tests after changing a simple version string
> - even if one does not expect any compile issues and just want to see
> the impact in a CI/CD environment
>
> The current "generate in the build" is tied to "package".
>
>
>> Am Mittwoch, dem 09.02.2022 um 15:33 +0100 schrieb Jean-Louis Monteiro:
>> Thanks David for the extra infra information. That makes the
>> automation a
>> bit harder indeed.
>>
>> Let's keep the "generate in the build" as it is today and see if we
>> can
>> remember to push and when I say we, I mean "I" 😀
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Wed, Feb 9, 2022 at 3:15 PM David Blevins <db...@tomitribe.com>
>> wrote:
>>
>>> 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 <
>>> jlmonteiro@tomitribe.com>
>>> 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
>>>>
>>> --
>>> Sent from Gmail Mobile
>>>
Re: Generated BOM files
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
I think, that the inconvience originates from the fact, that one has to
conduct a quick build w/o tests after changing a simple version string
- even if one does not expect any compile issues and just want to see
the impact in a CI/CD environment
The current "generate in the build" is tied to "package".
Am Mittwoch, dem 09.02.2022 um 15:33 +0100 schrieb Jean-Louis Monteiro:
> Thanks David for the extra infra information. That makes the
> automation a
> bit harder indeed.
>
> Let's keep the "generate in the build" as it is today and see if we
> can
> remember to push and when I say we, I mean "I" 😀
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Feb 9, 2022 at 3:15 PM David Blevins <db...@tomitribe.com>
> wrote:
>
> > 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 <
> > jlmonteiro@tomitribe.com>
> > 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
> > >
> > --
> > Sent from Gmail Mobile
> >
Re: Generated BOM files
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Thanks David for the extra infra information. That makes the automation a
bit harder indeed.
Let's keep the "generate in the build" as it is today and see if we can
remember to push and when I say we, I mean "I" 😀
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Feb 9, 2022 at 3:15 PM David Blevins <db...@tomitribe.com> wrote:
> 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 <
> jlmonteiro@tomitribe.com>
> 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
> >
> --
> Sent from Gmail Mobile
>
Re: Generated BOM files
Posted by David Blevins <db...@tomitribe.com>.
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 <jl...@tomitribe.com>
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
>
--
Sent from Gmail Mobile