https://github.com/apache/solr/pull/2196
~ David On Wed, Sep 6, 2023 at 11:17 PM David Smiley <david.w.smi...@gmail.com> wrote: > Honestly, I would prefer to do away with it entirely. Dubious logic that > has been made to only output a warning will continue to be a part of the > code weight of our sprawling build. It will need to be maintained[1]. It > needs to do it's calculations on every check/precommit. I don't even want > to be "warned" about the fact that I am modifying files. *Of course* > there are modified files; I am actually work on this codebase! > > [1] even making it have a computed default is an example of this > maintenance cost! > > ~ David > > > On Wed, Sep 6, 2023 at 8:46 PM Michael Gibney <mich...@michaelgibney.net> > wrote: > >> Something like this could work?: >> >> >> https://github.com/apache/solr/blob/eaaabbfa33456639613a7a6aecc37cd2d89e5dfa/gradle/globals.gradle#L168-L171 >> >> On Wed, Sep 6, 2023 at 5:26 PM David Smiley <david.w.smi...@gmail.com> >> wrote: >> > >> > Is there a property or something used to detect that the build is being >> run >> > in a CI or CI-like env? >> > ~ David >> > >> > >> > On Wed, Sep 6, 2023 at 4:50 PM Shawn Heisey <apa...@elyograg.org> >> wrote: >> > >> > > On 9/6/23 13:21, Uwe Schindler wrote: >> > > > The idea is that jenkins runs it after the builds to figure out if >> > > > something changed in the working copy. At ANT times this was >> implemented >> > > > exactly like this, we failed build on Jenkins when the working copy >> > > > changed. This was especially important before we used >> SecurityManager to >> > > > prevent tests writing outside their temporary dirs. We had tests >> > > > touching files in working copy. >> > > >> > > That makes sense, and for Jenkins it sounds like a very good idea. I >> > > think that Jenkins should probably explicitly request that check ... >> > > having it enabled by default for everyone is not the best idea IMHO. >> > > >> > > Thanks, >> > > Shawn >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> > > For additional commands, e-mail: dev-h...@solr.apache.org >> > > >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >>
