One function in Jenkinsfile is sick. It is pure bureaucracy where the Jenkinsfile becomes a beton. There is no freedom for developers in Jenkinsfile in that case.
The build does not need to have Java 9. It's not the reason to invest effort. I invest effort to Jigsaw support, JUnit5 and 3.0. It is quite a lot of work. Do not try to see it from one direction only. On Sat, Dec 2, 2017 at 11:23 AM, Stephen Connolly < [email protected]> wrote: > On Sat 2 Dec 2017 at 10:03, Tibor Digana <[email protected]> wrote: > > > Pls do not do it! > > I want to have it under control in Jenkinsfile and not to share the code > > with other projects. > > > I do not see that you actually have anything that needs a custom build. > > We can add code coverage to the template. > > The only repo I see with reasonable excuses for a custom Jenkinsfile is the > core Maven itself... and that’s only because of the core integration tests. > > > > Surefire project is different and it must be still different. > > > Certainly you have moved the build that way... i’d Like to see explicit > reasons why surefire cannot use the standard build. Snowflake builds do not > help grow community. > > > > I see Groovy libraries useful only in situations when I call Hudson API > > functions and I need to avoid security issue on these calls after using > > shared Groovy library for Jenkins, but not in here like one function > > substituting entire content of Jenkinsfile. > > > There are many use cases for shared libraries. Do not limit yourself to one > small (and in my view antipattern) use case > > > > > > T > > > > On Thu, Nov 30, 2017 at 10:59 PM, Stephen Connolly < > > [email protected]> wrote: > > > > > https://builds.apache.org/job/maven-wip/job/maven-surefire/ > > > job/new-jenkinsfile/ > > > to see what it's like. > > > > > > We can look into adding jacoco reporting to the standard build if it is > > > seen as important > > > > > > -- > Sent from my phone >
