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

Reply via email to