Hi Gerhard, > i'm not sure if others are still following it. at the time i did the > releases, it was a mandatory step.
Yes, I hope nobody releases without actually testing it at all. But this check IMO comes too late - there are multiple "fixes" present, where the author apparently didn't even execute the tests. Checking this before release means you bump into problems with issues which were "fixed" six months ago. Hence I am suggesting whether we shouldn't look into some more flexible approach. I know Travis still isn't quite the thing beucase of the structure, I am just trying to start a discussion here and see how people view thing - maybe I am just weird with my requirements :) > back then i also added ci-jobs for new owb/weld releases immediately. > (it looks like nobody took over that part.) Would be great if this was still done, every new weld release is announced directly on DS mailing list, so it's just about updating it. Matej ----- Original Message ----- > From: "Gerhard Petracek" <gpetra...@apache.org> > To: dev@deltaspike.apache.org > Sent: Thursday, November 30, 2017 3:32:04 PM > Subject: Re: CI for DeltaSpike? > > hi matej, > > one of the (manual) steps for a release is to check those results (before a > release gets started at all). > i'm not sure if others are still following it. at the time i did the > releases, it was a mandatory step. > back then i also added ci-jobs for new owb/weld releases immediately. > (it looks like nobody took over that part.) > > regards, > gerhard > > > > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > > Sorry Matej, I don't get how Travis would help since you can do the > > same with jenkins which is already configured. > > > > Having the default build running on both weld and OWB would be more > > beneficial IMHO, but it is just the opinion from my side of the fence > > and experience. > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com>: > > > Thanks, but it was more of a rhetorical question (you saved me some > > digging though). > > > Still my claim holds true, nobody cares about them much. They must have > > been failing for quite some time now > > > Not to mention they aren't even updated to latest Weld version (or > > WildFly version for that matter). > > > > > > > > > Matej > > > > > > ----- Original Message ----- > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com> > > >> To: dev@deltaspike.apache.org > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM > > >> Subject: Re: CI for DeltaSpike? > > >> > > >> Hi Matej, > > >> > > >> they are all on the ASF jenkins: > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/ > > >> > > >> Romain Manni-Bucau > > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn > > >> > > >> > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny <manov...@redhat.com>: > > >> > Hello > > >> > > > >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I > > meant > > >> > Integration OFC) and DeltaSpike. > > >> > Apparently, there is no such thing now and even while some CI jobs > > exist > > >> > (where are they, anyway?), nobody really pays attention to them. > > >> > I mean those for Weld ones must have been failing for few months and > > yet > > >> > the JIRAs causing that were happily marked as Resolved. > > >> > Meaning whoever fixed that probably only ran smoke tests with OWB. > > >> > > > >> > Today I noticed there is going to be a release soon and so I quikly > > went to > > >> > check how the build/tests fare with Weld profiles. > > >> > Turned out to be a disaster. So I then have to spend considerable time > > >> > backtracking the changes and figuring out the actual problem. > > >> > And it's not the first time this happened either. > > >> > > > >> > Therefore I wanted to bring up the topic of CI to avoid this in the > > future. > > >> > The ideal scenario is sending PRs and having them checked *before* > > merging > > >> > - obviously not an option here. > > >> > The GH repo is but a mirror (something we have to stick to I presume) > > which > > >> > makes it more complex, but still, it should be possible to set up a > > Travis > > >> > build on GH master which will execute after every sync. > > >> > That way the failures would be readily visible (via the travis status > > >> > "button"). > > >> > In order to discover most problems there is no need for a complete > > test > > >> > matrix, it would do to just have two version of OWB and Weld without > > EE > > >> > container (with just the Arq. one). > > >> > > > >> > > > >> > A penny for your thoughts? > > >> > > > >> > > > >> > Regards > > >> > Matej > > >> > > >
