The main issues are that we're all independent contributors to DS, all with the same level of rights to write to the repo. We typically don't do PRs. We actually do have a PR job in Jenkins for those external parties that do raise PRs -> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike-PR-Builder/
As for the state of the builds, agreed that it's a pain point. We have too many permutations of our tests, and it's pretty hard to test all of them locally. We need to come up with either a definitive short list of tests to always run, or figure out a way to better modularize DeltaSpike to limit the impacts. I do still think it's worthwhile to re envision our pipeline to have better control over what tests are run and how they are managed. John On Wed, Nov 29, 2017 at 10:47 AM Matej Novotny <manov...@redhat.com> wrote: > 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 >
