Although no formal standards, many cloud-based CI environments agreed upon setting CI=true, and I think also Jenkins does that. It might be a relatively simple way to detect most CI environments.
The next question is what Maven should do with that information. I feel like informing the user is more in the Maven spirit (just as the fact that 3.7.0 warns when plugin versions aren't locked). Something like "you typically want to set -B in this case". Setting flags the user isn't aware of feels a bit odd to me. Thanks, Maarten On July 12th, 2020 at 21:19, Martin Kanters wrote: > Thanks for all the replies! > > I agree that checking on environment variables is not desirable (because of > the many different CI environments and also because the envs are not > necessarily unique to the CI environment only). > > Using some kind of mechanism Michael is proposing seems a lot more generic > and less error prone, definitely worth looking into if we decide to > implement this. > On the other hand I agree with Romain that if it is only about -B it might > not be worth the effort and added complexity. > > I propose to keep this idea of --force-interactive and --non-interactive in > mind for when we find another use-case next to -B. > > Thanks again, > Martin > > > Op zo 12 jul. 2020 om 19:48 schreef Romain Manni-Bucau < > [email protected]>: > >> Hi, >> >> Did you already do the work to list what it implies? >> For instance I know interactive mode can be needed on these platforms (for >> debug purposes mainly), that travis requires more work for logs (size + >> timeout "ping" log to not have the job killed) etc... >> So wonder what is the overlap (if it is just -B it is not worth to be >> extreme) and if we have that status. >> A small alternative which is interesting is to not enable/disable anything >> but log it is likely desired: "you are running on X, you should probably >> set -X1 -X2, or -no-X1 -noX2 if you dont want this message to show again". >> >> 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 dim. 12 juil. 2020 à 19:41, Michael Osipov <[email protected]> a >> écrit : >> >>> Am 2020-07-12 um 17:42 schrieb Martin Kanters: >>>> Hi all, >>>> >>>> When setting up GitHub Actions for Maven (core) two weeks ago, I >>> initially >>>> forgot to enable the -B/--batch-mode flag. >>>> While this gave no issues and was easy to fix, it could be avoided by >>>> detecting if Maven is executed on popular CI environments and in that >>> case >>>> automatically enabling batch mode. >>>> Popular CI tools such as GitHub Actions [1] and GitLab CI [2] provide >>>> predefined environment variables, which could be used for this purpose. >>>> When this would automatically activate, we log this on INFO level. We >>> would >>>> also need an option to turn batch-mode off to override this automatic >>>> behavior. >>>> >>>> The reason why I haven't created a JIRA issue yet is because I realize >> I >>> do >>>> not know if this fits the usual workings for Maven. >>>> Based on best guesses (de-)activating certain functionality can in my >>>> vision be a quality-of-life improvement for our users. >>>> On the other hand I have the feeling currently Maven does favor users >> to >>>> explicitly set their CLI flags. >>>> Just wanted to know your opinion. If I get positive feedback I will >>> create >>>> a JIRA issue. >>>> Otherwise we can consider alternatives (only log a hint: "CI run >>> detected, >>>> did you want to run in --batch-mode?") or leave it like it is. >>> >>> So, I consider explicitly adding zillions of CI support is the wrong way >>> to go. We need to be agnostic just like we are IDE-agnostic. >>> What you are basically looking for is just like in Subversion: >>>> --non-interactive : do no interactive prompting (default is to >>> prompt >>>> only if standard input is a terminal >> device) >>>> --force-interactive : do interactive prompting even if standard >>> input >>>> is not a terminal device >>> >>> by default Subversion will try to determine both. You need native code >>> here to determine whether stdout/stdin is attached to a terminal. There >>> you will have your auto detection. Java's Console is supposed to do >>> this, but is is too limited. >>> Luckily, we do have Jansi in tree which provides use with: >>> POSIX: >>> >>> >> https://github.com/fusesource/jansi-native/blob/master/src/main/java/org/fusesource/jansi/internal/CLibrary.java#L74-L76 >>> Windows: >>> >>> >> https://github.com/fusesource/jansi-native/blob/master/src/main/java/org/fusesource/jansi/internal/WindowsSupport.java#L49-L57 >>> >>> This is what you are looking for. >>> >>> Michael >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
