Le mer. 27 juin 2018 à 11:59, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> The multiple test run makes perfect sense. > The second round of test is performed against a clean checkout from the > tag. > That makes sure that the build is really reproducible. That's actually a > HUGE win and we introduced this in maven for good reasons! > Well with git you create the branch then run tests and then you don't have to do it agan ever since the hash is constant so you just loose time redoing it. This is why gitflow doesnt redo it for example. You would need to redo it only if you mutate the branch/tag which is a biggest issue if done anyway. > > > What do you propose? Assume we split in 2 repos, you get the exact same > > issue in the examples repo but need to build 2 repo in the release now, > > right? > > No, the examples do NOT get released. They already get kind of > half-excluded in our standard release. But just bei weird tricks like > setting a different distributionMangement which does not exist, etc. > Right but their tests are passed in the release process (and the release manager generally ensures they run on the release branch). > > > > > > Don't get that, you reduce openejb-core build removing examples which > > depends on openejb-core? It is not correlated normally. Can you give a > few > > more words on that please? > > No the examples do not depend on openejb-core but most times on the result > of the main build. > Or a different version hereof. > > > > Can you build master and commit having a green build with regression? > yes. > > so it gets worse. That's what i meant. > > It doesn't get worse. Because right now most committers don't even build > with tests enabled because it takes so long. > Any many of the tests did behave stochastic before I fixed them. And other > tests only worked with the system being set to en_US. > So people did solely rely on CI anyway it seems. > I want to change this and make committers more often run the tests locally > _before_ they commit. > And of course have CI of main TomEE + afterwards TomEE-Examples for > getting the CI quality as we have today. > My 2cts is that you will loose time going that way. When you do a fix you will not wait 3h to ensure it passes. Even you Mark never run -Pall-adapters which means you have ~1/3 of the actual coverage for several modules. We did a fastbuild profile to solve that local build time issue a long time ago. Maybe just invest in making it better? > > LieGrue, > strub > > > > Am 27.06.2018 um 11:35 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > Le mer. 27 juin 2018 à 11:22, Mark Struberg <strub...@yahoo.de.invalid> > a > > écrit : > > > >> Thanks for the feedback! > >> > >> > >>>> * they break the maven-release-plugin, because they don't use the same > >>>> version > >>>> > >>> > >>> Moving it to another repo will not solve it since they must be > >> independent > >>> and not have a common parent to be copiable and runnable without > >>> dependencies. > >> > >> Exactly that missing parent is the problem! > >> If we do not have the examples in the TomEE repo then this problem > simply > >> goes away! > >> And we do NOT release our examples anyway! > >> The deploy is explicitly disabled (with a few dirty tricks). > >> > >> > >>> Also I'm not sure we'll use the plugin anyway since it doesn't fit much > >> big > >>> projects and with git it is useless > >> > >> No, the maven-releas-plugin works perfectly fine even in huge projects. > >> > > > > It is more about the time consumption with no gain due to the multiple > test > > run. > > > > > >> The problem is that our current setup is really broken because those > >> examples sub modules miss the back reference to the reactor build. > >> > >> > >>> Each release manager should ensure it is bumped to next master version, > >> we > >>> can have missed it a bit but this is a bug we should fix. > >> > >> Most of them have been on different versions. Some 1.1-SNAPSHOT, some > >> 1.7.3-SNAPSHOT, others even 1.0-SNAPSHOT. > >> With other words: it was pretty much a mess because all the automation > >> which maven provides was NOT used. Instead the releases seem to have > been > >> performed manually. > >> > > > > Normally it is 1.0 (or 1.0.0) - SNAPSHOT, 1.1 can be a post release hack > or > > a need when some API has been broken (I have 2 cases in mind, no more) > > > > > >> > >> > >> > >>>> * We have many people who want to probably add samples without wanting > >> to > >>>> go through all the hassle to build full tomee > >>>> > >>> > >>> This is the case by design since they are independent. > >> > >> This is exactly the shizophrenic situation. They are part of the build - > >> but also not. It is really only half done right now. > >> > > > > What do you propose? Assume we split in 2 repos, you get the exact same > > issue in the examples repo but need to build 2 repo in the release now, > > right? > > > > > >> > >> > >>> I don't get what it changes here since if you drop 15mn you still have > >>> something like 3h to run. > >> > >> Build gets reduced to 20 minutes over here. A big part is openejb-core, > >> and of course also the TCKs. > >> > > > > Don't get that, you reduce openejb-core build removing examples which > > depends on openejb-core? It is not correlated normally. Can you give a > few > > more words on that please? > > > > > >> > >> > >> > >>> Anyaway if we go that path we can just contribute most of them back to > >>> javaee_samples and only keep our specific ones. > >> > >> Would love to keep them here so we can tweak them as we need and can > link > >> to the examples on our site. > >> > > > > Works for me, no strong opinion, was just thiking out loud. > > > > > >> > >>> To summarize it to make it very clear I'm +-0 (as really neutral since > it > >>> doesn't change anything at the end IMHO) to drop them IF (and only if) > >> the > >>> coverage is contributed back to the main project. > >> > >> The coverage doesn't get worse. It's then just split into two different > >> CIs. > >> > > > > Can you build master and commit having a green build with regression? > yes. > > so it gets worse. That's what i meant. > > > > > >> Even better: we can have an EE6 samples which we can test against new > and > >> old containers. > >> Plus an EE7 examples and EE8 examples project which can run against > newer > >> containers. > >> > > > > We align our examples on the branch so not a big advantage from my > window. > > > > > >> > >> But we certainly have to think about how to do the final setup. > >> > >> LieGrue, > >> strub > >> > >> > >>> Anfang der weitergeleiteten Nachricht: > >>> > >>> Von: Romain Manni-Bucau <rmannibu...@gmail.com> > >>> Betreff: Aw: [DISCUSS] Extract examples into own git repo > >>> Datum: 27. Juni 2018 um 11:01:19 MESZ > >>> An: dev@tomee.apache.org > >>> Antwort an: dev@tomee.apache.org > >>> > >>> Hi Mark, > >>> > >>> think we already discuss it somewhere else but wrote again the points > >>> inline if it has been missed > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>> <https://rmannibucau.metawerx.net/> | Old Blog > >>> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau> | > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>> < > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>> > >>> > >>> > >>> Le mer. 27 juin 2018 à 10:48, Mark Struberg <strub...@yahoo.de.invalid > > > >> a > >>> écrit : > >>> > >>>> Hi folks! > >>>> > >>>> While trying to release TomEE-7.0.5 I figured that the Examples as > part > >> of > >>>> the TomEE core project are really counter productive. > >>>> > >>>> * they break the maven-release-plugin, because they don't use the same > >>>> version > >>>> > >>> > >>> Moving it to another repo will not solve it since they must be > >> independent > >>> and not have a common parent to be copiable and runnable without > >>> dependencies. They should also depend on current tomee snapshot and be > >>> aligned on tomee lifecycle for that reason(cause they can show feature > we > >>> just added on master). Not sure how you plan to solve it in another > repo > >>> but doable. > >>> > >>> Also I'm not sure we'll use the plugin anyway since it doesn't fit much > >> big > >>> projects and with git it is useless to go through the full lifecycle > (you > >>> use local branches/tags you push later so no potential conflicts like > you > >>> can have with svn). You can save half of the release time not using it > >> ;). > >>> > >>> > >>>> * They pollute the build (samples alone take 15 minutes of our build), > >>>> which might lower contributions > >>>> > >>> > >>> See it the other way around. It is part of the build cause mainly used > as > >>> integration tests for a big part of them so if you drop them you must > >> move > >>> all the tests to the main build before doing it which will lead to just > >>> save ~5mn on 3h of build (CI). > >>> > >>> > >>>> * They are bound to a specific tomee version, so they cannot easily be > >>>> tested against another version > >>>> > >>> > >>> Each release manager should ensure it is bumped to next master version, > >> we > >>> can have missed it a bit but this is a bug we should fix. > >>> > >>> > >>>> * We have many people who want to probably add samples without wanting > >> to > >>>> go through all the hassle to build full tomee > >>>> > >>> > >>> This is the case by design since they are independent. > >>> > >>> > >>>> > >>>> Of course there are also downsides, mainly: > >>>> * by having the samples as part of our build we also have improved > test > >>>> coverage. > >>>> > >>>> Well, since right now almost nobody runs the tests when building TomEE > >>>> (but instead rely on our CI, because it takes so long) it makes no > >>>> difference anyway. I'd rather have a core project with decently good > >> test > >>>> coverage - and people also run it - than having a bit better coverage > >>>> which nobody runs. > >>>> > >>> > >>> I don't get what it changes here since if you drop 15mn you still have > >>> something like 3h to run. > >>> > >>> > >>>> > >>>> So I propose to move the Examples to a separate repo and add a > separate > >> CI > >>>> for it. > >>>> > >>> > >>> Anyaway if we go that path we can just contribute most of them back to > >>> javaee_samples and only keep our specific ones. > >>> > >>> > >>>> Of course we should look at how to set it up so we can have samples > for > >>>> multiple EE versions. > >>>> > >>> > >>> Our site is not versionned (think we said it was too costly to maintain > >> to > >>> do it earlier, not sure we still stand on that point) so not sure it is > >>> important. However we must still generate the example pages etc in our > >> site > >>> generation so if they move we should ensure it is not broken. > >>> > >>> > >>>> > >>>> wdyt? > >>>> > >>> > >>> To summarize it to make it very clear I'm +-0 (as really neutral since > it > >>> doesn't change anything at the end IMHO) to drop them IF (and only if) > >> the > >>> coverage is contributed back to the main project. > >>> > >>> > >>>> > >>>> LieGrue, > >>>> strub > >
