Re: RE switching surefire to the standard build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RE switching surefire to the standard build

Tibor Digana
Pls do not do it!
I want to have it under control in Jenkinsfile and not to share the code
with other projects.
Surefire project is different and it must be still different.
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.

T

On Thu, Nov 30, 2017 at 10:59 PM, Stephen Connolly <
[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: RE switching surefire to the standard build

stephenconnolly
On Sat 2 Dec 2017 at 10:03, Tibor Digana <[hidden email]> 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 <
> [hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: RE switching surefire to the standard build

Tibor Digana
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 <
[hidden email]> wrote:

> On Sat 2 Dec 2017 at 10:03, Tibor Digana <[hidden email]> 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 <
> > [hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: RE switching surefire to the standard build

stephenconnolly
On Sat 2 Dec 2017 at 10:42, Tibor Digana <[hidden email]> wrote:

> 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.


If you don’t want Java 9 then you can turn off Java 9 using the parameters.

Now the larger question is why we cannot build with Java 9...

Any snowflake build is a code smell

Any build needing complex Jenkinsfile logic is a code smell

Now if you are in the position where surefire cannot build with Java 9 but
you need to run tests with Java 9... that would be an acceptable reason...
but ultimately we will need to solve the Java 9 issues so that surefire is
able to use the standard build.

TL;DR if you cannot use the standard build, then there is a barrier on new
contributors as they cannot “just build”, instead they need to understand
how to build.


>
> 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 <
> [hidden email]> wrote:
>
> > On Sat 2 Dec 2017 at 10:03, Tibor Digana <[hidden email]> 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 <
> > > [hidden email]> 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
> >
>
--
Sent from my phone