hi matej, imo the main point here is that in the past we received too many wrong failures and almost no commit really broke the backward compatibility.
regards, gerhard 2017-12-01 11:49 GMT+01:00 Matej Novotny <[email protected]>: > 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" <[email protected]> > > To: [email protected] > > 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 <[email protected]>: > > > > > 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 <[email protected]>: > > > > 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" <[email protected]> > > > >> To: [email protected] > > > >> 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 <[email protected]>: > > > >> > 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 > > > >> > > > > > >
