Re: Jenkins JDK Matrix - and consolidating of versions.

2016-08-01 Thread Ismael Juma
Hi,

On Mon, Aug 1, 2016 at 4:14 AM, Gav  wrote:

> JDK 1.4 (latest), JDK 1.5 (latest), JDK 1.6 (latest), JDK 1.7 (latest), JDK
> 1.8 (latest)
>
> All point to the very latest (and in some cases last) publically available
> release as of today.


Thanks for doing this, I have updated Kafka Jenkins builds to use JDK 1.7
(latest) and JDK 1.8 (latest).

Ismael


Re: Jenkins JDK Matrix - and consolidating of versions.

2016-08-02 Thread Ismael Juma
Hi,

We had a couple of failed Kafka builds using JDK 1.8 (latest) where the JDK
was not found:

https://builds.apache.org/job/kafka-trunk-jdk8/793/
https://builds.apache.org/job/kafka-trunk-jdk8/794/

The JDK was found OK in the previous build:

https://builds.apache.org/job/kafka-trunk-jdk8/792/

Maybe a misconfiguration in "jenkins-test-24f"?

Ismael

On Mon, Aug 1, 2016 at 12:39 PM, Ismael Juma  wrote:

> Hi,
>
> On Mon, Aug 1, 2016 at 4:14 AM, Gav  wrote:
>
>> JDK 1.4 (latest), JDK 1.5 (latest), JDK 1.6 (latest), JDK 1.7 (latest),
>> JDK
>> 1.8 (latest)
>>
>> All point to the very latest (and in some cases last) publically available
>> release as of today.
>
>
> Thanks for doing this, I have updated Kafka Jenkins builds to use JDK 1.7
> (latest) and JDK 1.8 (latest).
>
> Ismael
>


Issues with Kafka PR builds since Jenkins emergency restart

2017-04-27 Thread Ismael Juma
Hi,

As explained in INFRA-14011[1], we're having issues with Kafka PR builds
since the recent Jenkins restart.

Builds hang for a long time with the message:

"GitHub pull request #2301 of commit
0cc900288e61b05b4095b63d28969e16167e5d88, no merge conflicts."[2]

This is problematic for Kafka (we generally only merge PRs when builds are
green), but also for other projects because these builds are taking a lot
of executor slots for long periods of time and not doing anything.

In one of the builds that I interrupted, there were some errors related to
API rate limits:

Unable to query GitHub for status of
PullRequestjava.io.InterruptedIOException
at org.kohsuke.github.RateLimitHandler$1.onError(RateLimitHandler.java:41)
at org.kohsuke.github.Requester.handleApiError(Requester.java:666)
at org.kohsuke.github.Requester._to(Requester.java:283)
at org.kohsuke.github.Requester.to(Requester.java:231)
at org.kohsuke.github.GHPullRequest.populate(GHPullRequest.java:207)
at org.kohsuke.github.GHPullRequest.getMergeable(GHPullRequest.java:170)
at org.jenkinsci.plugins.ghprb.GhprbBuilds.onStarted(GhprbBuilds.java:101)
at
org.jenkinsci.plugins.ghprb.GhprbBuildListener.onStarted(GhprbBuildListener.java:18)
at hudson.model.listeners.RunListener.fireStarted(RunListener.java:240)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Caused by: org.kohsuke.github.HttpException: {"message":"API rate limit
exceeded for asfbot.","documentation_url":"
https://developer.github.com/v3/#rate-limiting"}
at org.kohsuke.github.Requester.handleApiError(Requester.java:654)
... 11 more
Caused by: org.kohsuke.github.HttpException: Server returned HTTP response
code: 403, message: 'Forbidden' for URL:
https://api.github.com/repos/apache/kafka/pulls/2910
at org.kohsuke.github.Requester.parse(Requester.java:612)
at org.kohsuke.github.Requester._to(Requester.java:262)
... 10 more
Caused by: java.io.IOException: Server returned HTTP response code: 403 for
URL: https://api.github.com/repos/apache/kafka/pulls/2910
at sun.reflect.GeneratedConstructorAccessor241.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1926)
at
sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1921)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1920)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1490)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at org.kohsuke.github.Requester.parse(Requester.java:596)
... 11 more
Caused by: java.io.IOException: Server returned HTTP response code: 403 for
URL: https://api.github.com/repos/apache/kafka/pulls/2910
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at org.kohsuke.github.Requester.parse(Requester.java:586)
... 11 more
Setting status of b5df4d319bc65e847a8c18ad20660f3e506e9a16 to PENDING with
url https://builds.apache.org/job/kafka-pr-jdk7-scala2.10/3201/ and
message: 'Build started sha1 is original commit.'[3]

Could this be a hint of the underlying issue?

These problems are affecting the following jobs:

https://builds.apache.org/job/kafka-pr-jdk7-scala2.10
https://builds.apache.org/job/kafka-pr-jdk8-scala2.11
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12

Thanks for your help.

Ismael

[1] https://issues.apache.org/jira/browse/INFRA-14011
[2] https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3201/console
[3] https://builds.apache.org/job/kafka-pr-jdk7-scala2.10/3201/console


Re: Issues with Kafka PR builds since Jenkins emergency restart

2017-04-27 Thread Ismael Juma
Thanks!

Ismael

On Thu, Apr 27, 2017 at 11:53 AM, Gavin McDonald 
wrote:

> Hi,
>
> Yes, we have contacted Github Support about the rate limit, and are yet to
> hear back.
>
> Will let you know when we hear something.
>
> Gav… (ASF Infra)
>
> > On 27 Apr 2017, at 8:16 pm, Ismael Juma  wrote:
> >
> > Hi,
> >
> > As explained in INFRA-14011[1], we're having issues with Kafka PR builds
> > since the recent Jenkins restart.
> >
> > Builds hang for a long time with the message:
> >
> > "GitHub pull request #2301 of commit
> > 0cc900288e61b05b4095b63d28969e16167e5d88, no merge conflicts."[2]
> >
> > This is problematic for Kafka (we generally only merge PRs when builds
> are
> > green), but also for other projects because these builds are taking a lot
> > of executor slots for long periods of time and not doing anything.
> >
> > In one of the builds that I interrupted, there were some errors related
> to
> > API rate limits:
> >
> > Unable to query GitHub for status of
> > PullRequestjava.io.InterruptedIOException
> > at org.kohsuke.github.RateLimitHandler$1.onError(
> RateLimitHandler.java:41)
> > at org.kohsuke.github.Requester.handleApiError(Requester.java:666)
> > at org.kohsuke.github.Requester._to(Requester.java:283)
> > at org.kohsuke.github.Requester.to(Requester.java:231)
> > at org.kohsuke.github.GHPullRequest.populate(GHPullRequest.java:207)
> > at org.kohsuke.github.GHPullRequest.getMergeable(GHPullRequest.java:170)
> > at org.jenkinsci.plugins.ghprb.GhprbBuilds.onStarted(
> GhprbBuilds.java:101)
> > at
> > org.jenkinsci.plugins.ghprb.GhprbBuildListener.onStarted(
> GhprbBuildListener.java:18)
> > at hudson.model.listeners.RunListener.fireStarted(RunListener.java:240)
> > at hudson.model.Run.execute(Run.java:1724)
> > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> > at hudson.model.ResourceController.execute(ResourceController.java:98)
> > at hudson.model.Executor.run(Executor.java:404)
> > Caused by: org.kohsuke.github.HttpException: {"message":"API rate limit
> > exceeded for asfbot.","documentation_url":"
> > https://developer.github.com/v3/#rate-limiting"}
> > at org.kohsuke.github.Requester.handleApiError(Requester.java:654)
> > ... 11 more
> > Caused by: org.kohsuke.github.HttpException: Server returned HTTP
> response
> > code: 403, message: 'Forbidden' for URL:
> > https://api.github.com/repos/apache/kafka/pulls/2910
> > at org.kohsuke.github.Requester.parse(Requester.java:612)
> > at org.kohsuke.github.Requester._to(Requester.java:262)
> > ... 10 more
> > Caused by: java.io.IOException: Server returned HTTP response code: 403
> for
> > URL: https://api.github.com/repos/apache/kafka/pulls/2910
> > at sun.reflect.GeneratedConstructorAccessor241.newInstance(Unknown
> Source)
> > at
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> DelegatingConstructorAccessorImpl.java:45)
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> > at
> > sun.net.www.protocol.http.HttpURLConnection$10.run(
> HttpURLConnection.java:1926)
> > at
> > sun.net.www.protocol.http.HttpURLConnection$10.run(
> HttpURLConnection.java:1921)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> > sun.net.www.protocol.http.HttpURLConnection.getChainedException(
> HttpURLConnection.java:1920)
> > at
> > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(
> HttpURLConnection.java:1490)
> > at
> > sun.net.www.protocol.http.HttpURLConnection.getInputStream(
> HttpURLConnection.java:1474)
> > at
> > sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(
> HttpsURLConnectionImpl.java:254)
> > at org.kohsuke.github.Requester.parse(Requester.java:596)
> > ... 11 more
> > Caused by: java.io.IOException: Server returned HTTP response code: 403
> for
> > URL: https://api.github.com/repos/apache/kafka/pulls/2910
> > at
> > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(
> HttpURLConnection.java:1876)
> > at
> > sun.net.www.protocol.http.HttpURLConnection.getInputStream(
> HttpURLConnection.java:1474)
> > at java.net.HttpURLConnection.getResponseCode(
> HttpURLConnection.java:480)
> > at
> > sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(
> HttpsURLConnectionImpl.java:338)
> > at org.kohsuke.github.Requester.parse(Requester.java:586)
> > ... 11 more
> > Setting status of b5df4d319bc65e847a8c18ad20660f3e

Re: Issues with Kafka PR builds since Jenkins emergency restart

2017-04-28 Thread Ismael Juma
Everything is back to normal.

Thanks,
Ismael

On Thu, Apr 27, 2017 at 1:37 PM, Ismael Juma  wrote:

> Thanks!
>
> Ismael
>
> On Thu, Apr 27, 2017 at 11:53 AM, Gavin McDonald 
> wrote:
>
>> Hi,
>>
>> Yes, we have contacted Github Support about the rate limit, and are yet
>> to hear back.
>>
>> Will let you know when we hear something.
>>
>> Gav… (ASF Infra)
>>
>> > On 27 Apr 2017, at 8:16 pm, Ismael Juma  wrote:
>> >
>> > Hi,
>> >
>> > As explained in INFRA-14011[1], we're having issues with Kafka PR builds
>> > since the recent Jenkins restart.
>> >
>> > Builds hang for a long time with the message:
>> >
>> > "GitHub pull request #2301 of commit
>> > 0cc900288e61b05b4095b63d28969e16167e5d88, no merge conflicts."[2]
>> >
>> > This is problematic for Kafka (we generally only merge PRs when builds
>> are
>> > green), but also for other projects because these builds are taking a
>> lot
>> > of executor slots for long periods of time and not doing anything.
>> >
>> > In one of the builds that I interrupted, there were some errors related
>> to
>> > API rate limits:
>> >
>> > Unable to query GitHub for status of
>> > PullRequestjava.io.InterruptedIOException
>> > at org.kohsuke.github.RateLimitHandler$1.onError(RateLimitHandl
>> er.java:41)
>> > at org.kohsuke.github.Requester.handleApiError(Requester.java:666)
>> > at org.kohsuke.github.Requester._to(Requester.java:283)
>> > at org.kohsuke.github.Requester.to(Requester.java:231)
>> > at org.kohsuke.github.GHPullRequest.populate(GHPullRequest.java:207)
>> > at org.kohsuke.github.GHPullRequest.getMergeable(GHPullRequest.
>> java:170)
>> > at org.jenkinsci.plugins.ghprb.GhprbBuilds.onStarted(GhprbBuild
>> s.java:101)
>> > at
>> > org.jenkinsci.plugins.ghprb.GhprbBuildListener.onStarted(Ghp
>> rbBuildListener.java:18)
>> > at hudson.model.listeners.RunListener.fireStarted(RunListener.java:240)
>> > at hudson.model.Run.execute(Run.java:1724)
>> > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>> > at hudson.model.ResourceController.execute(ResourceController.java:98)
>> > at hudson.model.Executor.run(Executor.java:404)
>> > Caused by: org.kohsuke.github.HttpException: {"message":"API rate limit
>> > exceeded for asfbot.","documentation_url":"
>> > https://developer.github.com/v3/#rate-limiting"}
>> > at org.kohsuke.github.Requester.handleApiError(Requester.java:654)
>> > ... 11 more
>> > Caused by: org.kohsuke.github.HttpException: Server returned HTTP
>> response
>> > code: 403, message: 'Forbidden' for URL:
>> > https://api.github.com/repos/apache/kafka/pulls/2910
>> > at org.kohsuke.github.Requester.parse(Requester.java:612)
>> > at org.kohsuke.github.Requester._to(Requester.java:262)
>> > ... 10 more
>> > Caused by: java.io.IOException: Server returned HTTP response code: 403
>> for
>> > URL: https://api.github.com/repos/apache/kafka/pulls/2910
>> > at sun.reflect.GeneratedConstructorAccessor241.newInstance(Unknown
>> Source)
>> > at
>> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> > at
>> > sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLCo
>> nnection.java:1926)
>> > at
>> > sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLCo
>> nnection.java:1921)
>> > at java.security.AccessController.doPrivileged(Native Method)
>> > at
>> > sun.net.www.protocol.http.HttpURLConnection.getChainedExcept
>> ion(HttpURLConnection.java:1920)
>> > at
>> > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(
>> HttpURLConnection.java:1490)
>> > at
>> > sun.net.www.protocol.http.HttpURLConnection.getInputStream(H
>> ttpURLConnection.java:1474)
>> > at
>> > sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputSt
>> ream(HttpsURLConnectionImpl.java:254)
>> > at org.kohsuke.github.Requester.parse(Requester.java:596)
>> > ... 11 more
>> > Caused by: java.io.IOException: Server returned HTTP response code: 403
>> for
>> > URL: https://api.github.com/repos/apache/kafka/pulls/2910
>> > at
>> > sun.net.www.protocol.http.HttpURLConnecti

Re: jenkins emergency restart notice - Tues 00:00 UTC

2017-07-18 Thread Ismael Juma
Hi,

Thanks for the heads up. Was this done? We are still seeing "too many open
files" issues in Kafka builds. One example of many:

https://builds.apache.org/job/kafka-trunk-jdk7/lastCompletedBuild/console

Ismael

On Mon, Jul 17, 2017 at 2:53 PM, Chris Lambertus  wrote:

>
> Jenkins will be restarted at midnight tonight UTC to address problems
> related to ‘too many open files’ and to attempt to correct a problem with
> some windows agents. I will be stopping new builds so that the queue can
> empty over the next 2 hours.
>
> -Chris
>
>


Re: Ready for JDK 9 ?

2017-08-08 Thread Ismael Juma
Hi Rory,

Regarding Apache Kafka, we are getting closer (the recently released Gradle
4.1 helped), but there are a few blockers before our test suite passes:

1. EasyMock: https://github.com/easymock/easymock/issues/193. There is a PR
(https://github.com/easymock/easymock/pull/200), but it's blocked by
https://issues.apache.org/jira/browse/MSHADE-258.

2. PowerMock: https://github.com/powermock/powermock/issues/783

Generally, a final release of ASM 6 and a working maven-shade-plugin would
go a long way.

Hope that helps.

Ismael


On Tue, Aug 8, 2017 at 10:39 AM, Rory O'Donnell 
wrote:

>
> Hi Mark & Gavin,
>
> Thank you very much for all your testing of JDK 9 during its development!
> Such contributions have significantly helped shape and improve JDK 9.
>
> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
> would like to ask if your project can be considered to be 'ready for JDK
> 9', or if there are any remaining show stopper issues which you've
> encountered when testing with the JDK 9 release candidate.
>
> JDK 9  b181 is available at http://jdk.java.net/9/
>
> If you have a public web page, mailing list post, or even a tweet
> announcing you project's readiness for JDK 9, I'd love to add the URL to
> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>
>
> Looking forward to hearing from you,
> Rory
>
> [1] http://openjdk.java.net/projects/jdk9/
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


Re: Ready for JDK 9 ?

2017-09-18 Thread Ismael Juma
To follow-up on this, the tests for Apache Kafka trunk now pass with Java
9. We have also added a PR build for Java 9 so it stays that way.

Ismael

On Tue, Aug 8, 2017 at 3:23 PM, Ismael Juma  wrote:

> Hi Rory,
>
> Regarding Apache Kafka, we are getting closer (the recently released
> Gradle 4.1 helped), but there are a few blockers before our test suite
> passes:
>
> 1. EasyMock: https://github.com/easymock/easymock/issues/193. There is a
> PR (https://github.com/easymock/easymock/pull/200), but it's blocked by
> https://issues.apache.org/jira/browse/MSHADE-258.
>
> 2. PowerMock: https://github.com/powermock/powermock/issues/783
>
> Generally, a final release of ASM 6 and a working maven-shade-plugin would
> go a long way.
>
> Hope that helps.
>
> Ismael
>
>
> On Tue, Aug 8, 2017 at 10:39 AM, Rory O'Donnell 
> wrote:
>
>>
>> Hi Mark & Gavin,
>>
>> Thank you very much for all your testing of JDK 9 during its development!
>> Such contributions have significantly helped shape and improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
>> would like to ask if your project can be considered to be 'ready for JDK
>> 9', or if there are any remaining show stopper issues which you've
>> encountered when testing with the JDK 9 release candidate.
>>
>> JDK 9  b181 is available at http://jdk.java.net/9/
>>
>> If you have a public web page, mailing list post, or even a tweet
>> announcing you project's readiness for JDK 9, I'd love to add the URL to
>> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>>
>>
>> Looking forward to hearing from you,
>> Rory
>>
>> [1] http://openjdk.java.net/projects/jdk9/
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>>
>


Re: Release Announcement: General Availability of JDK 9

2017-09-21 Thread Ismael Juma
Apache Kafka is JDK 9 ready (it builds and all tests pass with Java 9).

Ismael

On Thu, Sep 21, 2017 at 9:28 PM, Rory O'Donnell 
wrote:

> Hi Mark & Gavin,
>
> Three items to share with you today
>
>  * *JDK 9 General Availability
>*
>  o GPL'd binaries from Oracle are available here:
>  + http://jdk.java.net/9
>  o See Mark Reinhold's email for more details on the Release [1]
>  + delivery of Project Jigsaw [2]
>
>  * Are you JDK 9 Ready ?
>  o The Quality Outreach wiki has been updated to include a JDK 9
>Ready column.
>  o If you would like us to identify your project as JDK 9 ready ,
>please let me know and I will add it to the wiki.
>
>  * Quality Outreach Report for September 2017**is available
>  o many thanks for your continued support and welcome to the new
>projects!
>
> Rgds,Rory
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2017-Septemb
> er/000230.html
> [2] https://mreinhold.org/blog/jigsaw-complete
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-09-24 Thread Ismael Juma
Hi Gavin,

To avoid running into problems when 9-b181 is removed, I changed Apache
Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do for Java
7 and Java 8) and got:

ERROR: JAVA_HOME is set to an invalid directory:
/home/jenkins/tools/java/latest1.9


Is the roll out of the final JDK 9 still in progress?

Thanks,
Ismael

On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald 
wrote:

> Hi All,
>
> As advertised on https://cwiki.apache.org/confluence/display/INFRA/JDK+
> Installation+Matrix , we will
> be removing some older JDK releases from Jenkins.
>
> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be removed
> within the next few days.
>
> Should your builds be using any of these, please migrate to a later
> version of JDK 1.8 or 9.
>
> Thanks
>
> Gav… (ASF Infra Team)
>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-09-24 Thread Ismael Juma
Thanks for the quick response. Seems like it was H25:

https://builds.apache.org/job/kafka-trunk-jdk9/57/

Ismael

On Sun, Sep 24, 2017 at 9:19 AM, Gavin McDonald 
wrote:

>
> > On 24 Sep 2017, at 5:47 pm, Ismael Juma  wrote:
> >
> > Hi Gavin,
> >
> > To avoid running into problems when 9-b181 is removed, I changed Apache
> > Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do for
> Java
> > 7 and Java 8) and got:
> >
> > ERROR: JAVA_HOME is set to an invalid directory:
> > /home/jenkins/tools/java/latest1.9
> >
> >
> > Is the roll out of the final JDK 9 still in progress?
>
> I spot checked on a few Jenkins slaves, can you tell me which one you
> failed on?
>
> Thanks
>
> Gav…
>
>
> gmcdonald@asf927:~$ /home/jenkins/tools/java/latest1.9/bin/java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>
> gmcdonald@asf914:~$ /home/jenkins/tools/java/latest1.9/bin/java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>
> gmcdonald@asf910:~$ /home/jenkins/tools/java/latest1.9/bin/java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>
> gmcdonald@asf900:~$ /home/jenkins/tools/java/latest1.9/bin/java -version
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>
>
> >
> > Thanks,
> > Ismael
> >
> > On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald 
> > wrote:
> >
> >> Hi All,
> >>
> >> As advertised on https://cwiki.apache.org/confluence/display/INFRA/JDK+
> >> Installation+Matrix , we will
> >> be removing some older JDK releases from Jenkins.
> >>
> >> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be removed
> >> within the next few days.
> >>
> >> Should your builds be using any of these, please migrate to a later
> >> version of JDK 1.8 or 9.
> >>
> >> Thanks
> >>
> >> Gav… (ASF Infra Team)
> >>
> >>
>
>


Re: Jenkins Github PR integration - Support for whitelisting?

2017-09-25 Thread Ismael Juma
Hi,

It is possible to use the plugin you call "official" too. It became
available some time ago and we (Apache Kafka) switched to it once we found
out. The easiest way is to look at our config:

https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/

Ismael

On Mon, Sep 25, 2017 at 8:02 AM, Jaikiran Pai 
wrote:

> Hello Build Team,
>
> I'm one of the committers of the Apache Ant project[1]. We use Jenkins
> hosted by the Infra team at builds.apache.org for automated triggering of
> specific Jenkins jobs for pull requests that are submitted at the
> (read-only) mirrors of the project hosted at github[2]. The Jenkins job is
> a typical job that follows the steps noted in this article[3]. Things work
> fine and here's the Jenkins job we have[4].
>
> However, a couple of things that seem to be missing when compared to the
> "official" Jenkins Github integration plugin[5] are:
>
> 1. Ability to whitelist users who can submit a PR - this helps to
> avoid random users from creating (potentially malicious) PRs which trigger
> a job against Jenkins
>
> 2. Ability to issue a "retest this please" command (by whitelisted
> users) as a comment on the PR to auto-trigger a new job for the PR.
>
> Are these features already available in the one that's hosted at
> builds.apache.org and if so, is there some documentation I can follow? If
> not, is there any workaround for #1 or any plans to support these features?
>
>
> [1] http://ant.apache.org/
>
> [2] https://github.com/apache/ant-ivy
>
> [3] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>
> [4] https://builds.apache.org/job/Ivy-GithubPR/
>
> [5] https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md
>
> -Jaikiran
>
>
>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-09-28 Thread Ismael Juma
Thanks. Another example we saw recently:

https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1524/console

Ismael

On Sun, Sep 24, 2017 at 11:06 AM, Gavin McDonald 
wrote:

>
> > On 24 Sep 2017, at 6:52 pm, Ismael Juma  wrote:
> >
> > Thanks for the quick response. Seems like it was H25:
>
> Thanks.
>
> So a regression in openjdk-9-jdk (b118) caused the node to not update from
> puppet
> any more, so the install and link for latest1.9 did not happen.
>
> Fixed, thanks for reporting.
>
> Gav…
>
> >
> > https://builds.apache.org/job/kafka-trunk-jdk9/57/
> >
> > Ismael
> >
> > On Sun, Sep 24, 2017 at 9:19 AM, Gavin McDonald 
> > wrote:
> >
> >>
> >>> On 24 Sep 2017, at 5:47 pm, Ismael Juma  wrote:
> >>>
> >>> Hi Gavin,
> >>>
> >>> To avoid running into problems when 9-b181 is removed, I changed Apache
> >>> Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do for
> >> Java
> >>> 7 and Java 8) and got:
> >>>
> >>> ERROR: JAVA_HOME is set to an invalid directory:
> >>> /home/jenkins/tools/java/latest1.9
> >>>
> >>>
> >>> Is the roll out of the final JDK 9 still in progress?
> >>
> >> I spot checked on a few Jenkins slaves, can you tell me which one you
> >> failed on?
> >>
> >> Thanks
> >>
> >> Gav…
> >>
> >>
> >> gmcdonald@asf927:~$ /home/jenkins/tools/java/latest1.9/bin/java
> -version
> >> java version "9"
> >> Java(TM) SE Runtime Environment (build 9+181)
> >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>
> >> gmcdonald@asf914:~$ /home/jenkins/tools/java/latest1.9/bin/java
> -version
> >> java version "9"
> >> Java(TM) SE Runtime Environment (build 9+181)
> >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>
> >> gmcdonald@asf910:~$ /home/jenkins/tools/java/latest1.9/bin/java
> -version
> >> java version "9"
> >> Java(TM) SE Runtime Environment (build 9+181)
> >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>
> >> gmcdonald@asf900:~$ /home/jenkins/tools/java/latest1.9/bin/java
> -version
> >> java version "9"
> >> Java(TM) SE Runtime Environment (build 9+181)
> >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>
> >>
> >>>
> >>> Thanks,
> >>> Ismael
> >>>
> >>> On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald <
> ga...@16degrees.com.au>
> >>> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> As advertised on https://cwiki.apache.org/
> confluence/display/INFRA/JDK+
> >>>> Installation+Matrix , we will
> >>>> be removing some older JDK releases from Jenkins.
> >>>>
> >>>> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be
> removed
> >>>> within the next few days.
> >>>>
> >>>> Should your builds be using any of these, please migrate to a later
> >>>> version of JDK 1.8 or 9.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Gav… (ASF Infra Team)
> >>>>
> >>>>
> >>
> >>
>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-09-28 Thread Ismael Juma
Thanks!

Ismael

On Fri, Sep 29, 2017 at 1:45 AM, Gavin McDonald 
wrote:

>
> > On 29 Sep 2017, at 10:13 am, Ismael Juma  wrote:
> >
> > Thanks. Another example we saw recently:
> >
> > https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1524/console
> >
>
> Thanks, fixed that node too.
>
> Will check for others.
>
> Gav…
>
> > Ismael
> >
> > On Sun, Sep 24, 2017 at 11:06 AM, Gavin McDonald  >
> > wrote:
> >
> >>
> >>> On 24 Sep 2017, at 6:52 pm, Ismael Juma  wrote:
> >>>
> >>> Thanks for the quick response. Seems like it was H25:
> >>
> >> Thanks.
> >>
> >> So a regression in openjdk-9-jdk (b118) caused the node to not update
> from
> >> puppet
> >> any more, so the install and link for latest1.9 did not happen.
> >>
> >> Fixed, thanks for reporting.
> >>
> >> Gav…
> >>
> >>>
> >>> https://builds.apache.org/job/kafka-trunk-jdk9/57/
> >>>
> >>> Ismael
> >>>
> >>> On Sun, Sep 24, 2017 at 9:19 AM, Gavin McDonald <
> ga...@16degrees.com.au>
> >>> wrote:
> >>>
> >>>>
> >>>>> On 24 Sep 2017, at 5:47 pm, Ismael Juma  wrote:
> >>>>>
> >>>>> Hi Gavin,
> >>>>>
> >>>>> To avoid running into problems when 9-b181 is removed, I changed
> Apache
> >>>>> Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do for
> >>>> Java
> >>>>> 7 and Java 8) and got:
> >>>>>
> >>>>> ERROR: JAVA_HOME is set to an invalid directory:
> >>>>> /home/jenkins/tools/java/latest1.9
> >>>>>
> >>>>>
> >>>>> Is the roll out of the final JDK 9 still in progress?
> >>>>
> >>>> I spot checked on a few Jenkins slaves, can you tell me which one you
> >>>> failed on?
> >>>>
> >>>> Thanks
> >>>>
> >>>> Gav…
> >>>>
> >>>>
> >>>> gmcdonald@asf927:~$ /home/jenkins/tools/java/latest1.9/bin/java
> >> -version
> >>>> java version "9"
> >>>> Java(TM) SE Runtime Environment (build 9+181)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>>>
> >>>> gmcdonald@asf914:~$ /home/jenkins/tools/java/latest1.9/bin/java
> >> -version
> >>>> java version "9"
> >>>> Java(TM) SE Runtime Environment (build 9+181)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>>>
> >>>> gmcdonald@asf910:~$ /home/jenkins/tools/java/latest1.9/bin/java
> >> -version
> >>>> java version "9"
> >>>> Java(TM) SE Runtime Environment (build 9+181)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>>>
> >>>> gmcdonald@asf900:~$ /home/jenkins/tools/java/latest1.9/bin/java
> >> -version
> >>>> java version "9"
> >>>> Java(TM) SE Runtime Environment (build 9+181)
> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> >>>>
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Ismael
> >>>>>
> >>>>> On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald <
> >> ga...@16degrees.com.au>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> As advertised on https://cwiki.apache.org/
> >> confluence/display/INFRA/JDK+
> >>>>>> Installation+Matrix , we will
> >>>>>> be removing some older JDK releases from Jenkins.
> >>>>>>
> >>>>>> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be
> >> removed
> >>>>>> within the next few days.
> >>>>>>
> >>>>>> Should your builds be using any of these, please migrate to a later
> >>>>>> version of JDK 1.8 or 9.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> Gav… (ASF Infra Team)
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-10-02 Thread Ismael Juma
Another node (H26):

"Building remotely on H26 <https://builds.apache.org/computer/H26>"
https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1640/console

Ismael

On Fri, Sep 29, 2017 at 2:41 AM, Ismael Juma  wrote:

> Thanks!
>
> Ismael
>
> On Fri, Sep 29, 2017 at 1:45 AM, Gavin McDonald 
> wrote:
>
>>
>> > On 29 Sep 2017, at 10:13 am, Ismael Juma  wrote:
>> >
>> > Thanks. Another example we saw recently:
>> >
>> > https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1524/console
>> >
>>
>> Thanks, fixed that node too.
>>
>> Will check for others.
>>
>> Gav…
>>
>> > Ismael
>> >
>> > On Sun, Sep 24, 2017 at 11:06 AM, Gavin McDonald <
>> ga...@16degrees.com.au>
>> > wrote:
>> >
>> >>
>> >>> On 24 Sep 2017, at 6:52 pm, Ismael Juma  wrote:
>> >>>
>> >>> Thanks for the quick response. Seems like it was H25:
>> >>
>> >> Thanks.
>> >>
>> >> So a regression in openjdk-9-jdk (b118) caused the node to not update
>> from
>> >> puppet
>> >> any more, so the install and link for latest1.9 did not happen.
>> >>
>> >> Fixed, thanks for reporting.
>> >>
>> >> Gav…
>> >>
>> >>>
>> >>> https://builds.apache.org/job/kafka-trunk-jdk9/57/
>> >>>
>> >>> Ismael
>> >>>
>> >>> On Sun, Sep 24, 2017 at 9:19 AM, Gavin McDonald <
>> ga...@16degrees.com.au>
>> >>> wrote:
>> >>>
>> >>>>
>> >>>>> On 24 Sep 2017, at 5:47 pm, Ismael Juma  wrote:
>> >>>>>
>> >>>>> Hi Gavin,
>> >>>>>
>> >>>>> To avoid running into problems when 9-b181 is removed, I changed
>> Apache
>> >>>>> Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do
>> for
>> >>>> Java
>> >>>>> 7 and Java 8) and got:
>> >>>>>
>> >>>>> ERROR: JAVA_HOME is set to an invalid directory:
>> >>>>> /home/jenkins/tools/java/latest1.9
>> >>>>>
>> >>>>>
>> >>>>> Is the roll out of the final JDK 9 still in progress?
>> >>>>
>> >>>> I spot checked on a few Jenkins slaves, can you tell me which one you
>> >>>> failed on?
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Gav…
>> >>>>
>> >>>>
>> >>>> gmcdonald@asf927:~$ /home/jenkins/tools/java/latest1.9/bin/java
>> >> -version
>> >>>> java version "9"
>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>> >>>>
>> >>>> gmcdonald@asf914:~$ /home/jenkins/tools/java/latest1.9/bin/java
>> >> -version
>> >>>> java version "9"
>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>> >>>>
>> >>>> gmcdonald@asf910:~$ /home/jenkins/tools/java/latest1.9/bin/java
>> >> -version
>> >>>> java version "9"
>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>> >>>>
>> >>>> gmcdonald@asf900:~$ /home/jenkins/tools/java/latest1.9/bin/java
>> >> -version
>> >>>> java version "9"
>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Ismael
>> >>>>>
>> >>>>> On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald <
>> >> ga...@16degrees.com.au>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi All,
>> >>>>>>
>> >>>>>> As advertised on https://cwiki.apache.org/
>> >> confluence/display/INFRA/JDK+
>> >>>>>> Installation+Matrix , we will
>> >>>>>> be removing some older JDK releases from Jenkins.
>> >>>>>>
>> >>>>>> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be
>> >> removed
>> >>>>>> within the next few days.
>> >>>>>>
>> >>>>>> Should your builds be using any of these, please migrate to a later
>> >>>>>> version of JDK 1.8 or 9.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> Gav… (ASF Infra Team)
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
>


Re: Deprecated JDKs being removed from Jenkins soon.

2017-10-04 Thread Ismael Juma
We had another Java 9 failure in H26. Would be great if this could be fixed.

Thanks!

Ismael

On Mon, Oct 2, 2017 at 10:00 PM, Ismael Juma  wrote:

> Another node (H26):
>
> "Building remotely on H26 <https://builds.apache.org/computer/H26>"
> https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1640/console
>
> Ismael
>
> On Fri, Sep 29, 2017 at 2:41 AM, Ismael Juma  wrote:
>
>> Thanks!
>>
>> Ismael
>>
>> On Fri, Sep 29, 2017 at 1:45 AM, Gavin McDonald 
>> wrote:
>>
>>>
>>> > On 29 Sep 2017, at 10:13 am, Ismael Juma  wrote:
>>> >
>>> > Thanks. Another example we saw recently:
>>> >
>>> > https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/1524/console
>>> >
>>>
>>> Thanks, fixed that node too.
>>>
>>> Will check for others.
>>>
>>> Gav…
>>>
>>> > Ismael
>>> >
>>> > On Sun, Sep 24, 2017 at 11:06 AM, Gavin McDonald <
>>> ga...@16degrees.com.au>
>>> > wrote:
>>> >
>>> >>
>>> >>> On 24 Sep 2017, at 6:52 pm, Ismael Juma  wrote:
>>> >>>
>>> >>> Thanks for the quick response. Seems like it was H25:
>>> >>
>>> >> Thanks.
>>> >>
>>> >> So a regression in openjdk-9-jdk (b118) caused the node to not update
>>> from
>>> >> puppet
>>> >> any more, so the install and link for latest1.9 did not happen.
>>> >>
>>> >> Fixed, thanks for reporting.
>>> >>
>>> >> Gav…
>>> >>
>>> >>>
>>> >>> https://builds.apache.org/job/kafka-trunk-jdk9/57/
>>> >>>
>>> >>> Ismael
>>> >>>
>>> >>> On Sun, Sep 24, 2017 at 9:19 AM, Gavin McDonald <
>>> ga...@16degrees.com.au>
>>> >>> wrote:
>>> >>>
>>> >>>>
>>> >>>>> On 24 Sep 2017, at 5:47 pm, Ismael Juma  wrote:
>>> >>>>>
>>> >>>>> Hi Gavin,
>>> >>>>>
>>> >>>>> To avoid running into problems when 9-b181 is removed, I changed
>>> Apache
>>> >>>>> Kafka's Jenkins jobs to use JDK 1.9 (latest) (which is what we do
>>> for
>>> >>>> Java
>>> >>>>> 7 and Java 8) and got:
>>> >>>>>
>>> >>>>> ERROR: JAVA_HOME is set to an invalid directory:
>>> >>>>> /home/jenkins/tools/java/latest1.9
>>> >>>>>
>>> >>>>>
>>> >>>>> Is the roll out of the final JDK 9 still in progress?
>>> >>>>
>>> >>>> I spot checked on a few Jenkins slaves, can you tell me which one
>>> you
>>> >>>> failed on?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>> Gav…
>>> >>>>
>>> >>>>
>>> >>>> gmcdonald@asf927:~$ /home/jenkins/tools/java/latest1.9/bin/java
>>> >> -version
>>> >>>> java version "9"
>>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>>> >>>>
>>> >>>> gmcdonald@asf914:~$ /home/jenkins/tools/java/latest1.9/bin/java
>>> >> -version
>>> >>>> java version "9"
>>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>>> >>>>
>>> >>>> gmcdonald@asf910:~$ /home/jenkins/tools/java/latest1.9/bin/java
>>> >> -version
>>> >>>> java version "9"
>>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>>> >>>>
>>> >>>> gmcdonald@asf900:~$ /home/jenkins/tools/java/latest1.9/bin/java
>>> >> -version
>>> >>>> java version "9"
>>> >>>> Java(TM) SE Runtime Environment (build 9+181)
>>> >>>> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>> Ismael
>>> >>>>>
>>> >>>>> On Sun, Sep 24, 2017 at 8:10 AM, Gavin McDonald <
>>> >> ga...@16degrees.com.au>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> Hi All,
>>> >>>>>>
>>> >>>>>> As advertised on https://cwiki.apache.org/
>>> >> confluence/display/INFRA/JDK+
>>> >>>>>> Installation+Matrix , we will
>>> >>>>>> be removing some older JDK releases from Jenkins.
>>> >>>>>>
>>> >>>>>> 1.8.0_92, 1.8.0_102, 9-b128, 9-b132, 9-b139, 9-b142 will all be
>>> >> removed
>>> >>>>>> within the next few days.
>>> >>>>>>
>>> >>>>>> Should your builds be using any of these, please migrate to a
>>> later
>>> >>>>>> version of JDK 1.8 or 9.
>>> >>>>>>
>>> >>>>>> Thanks
>>> >>>>>>
>>> >>>>>> Gav… (ASF Infra Team)
>>> >>>>>>
>>> >>>>>>
>>> >>>>
>>> >>>>
>>> >>
>>> >>
>>>
>>>
>>
>


Re: Jenkins needs to get kicked again.

2017-11-02 Thread Ismael Juma
Was the PR builder upgraded? We're seeing weird behaviour in our pull
requests where the PR status is added as a comment instead of updating the
PR status

https://github.com/apache/kafka/pull/3477#issuecomment-341471949

Ismael

On Wed, Nov 1, 2017 at 1:22 AM, Gavin McDonald 
wrote:

>
> > On 1 Nov 2017, at 10:36 am, Allen Wittenauer 
> wrote:
> >
> >
> >   It’s no longer scheduling jobs.
>
> Thanks Allen, looking into it. Also taking advantage of a required service
> restart to upgrade 60 outdated plugins.
>
> >
> >   Any clues as to why this happens?
>
> Not currently.
>
> Gav…
>
> >
> >
>
>


Re: Latest JDK 8 and 9 updated

2017-11-07 Thread Ismael Juma
Thanks Gavin! FYI, JDK 9.0.1 breaks Gradle versions older than 4.3. It
would be nice if Gradle 4.3 was available as an option in Jenkins (
https://issues.apache.org/jira/browse/INFRA-15448).

Ismael

On Sun, Oct 29, 2017 at 9:23 AM, Gavin McDonald 
wrote:

> Hi All,
>
> Just to inform that today ‘latest’ and ‘latest1.8’ now point to Oracle JDK
> 1.8.0_152
> And ‘latest1.9’ now points to Oracle jdk-9.0.1
>
> HTH
>
> Gav…
>
>


Re: Jenkins needs to get kicked again.

2017-11-07 Thread Ismael Juma
Thanks, that's very useful. Pretty weird that the behaviour of the PR
builder plugin changed with no config changes on our part or a version
upgrade. Fun! :)

Ismael

On Fri, Nov 3, 2017 at 12:54 AM, Gavin McDonald 
wrote:

>
> > On 3 Nov 2017, at 4:37 am, Chris Thistlethwaite 
> wrote:
> >
> > I don't have a current list of what was updated, but it's was up to date
> > before the issue today.
>
> We have a list of what plugins were upgraded and the From/To versions
> listed
> here:
>
> https://cwiki.apache.org/confluence/display/INFRA/Jenkins+Plugin+Upgrades
> <https://cwiki.apache.org/confluence/display/INFRA/Jenkins+Plugin+Upgrades
> >
>
> Gav…
>
> >
> >
> > -Chris T.
> >
> >
> > On 11/02/2017 01:15 PM, Ismael Juma wrote:
> >> Was the PR builder upgraded? We're seeing weird behaviour in our pull
> >> requests where the PR status is added as a comment instead of updating
> the
> >> PR status
> >>
> >> https://github.com/apache/kafka/pull/3477#issuecomment-341471949
> >>
> >> Ismael
> >>
> >> On Wed, Nov 1, 2017 at 1:22 AM, Gavin McDonald 
> >> wrote:
> >>
> >>>> On 1 Nov 2017, at 10:36 am, Allen Wittenauer <
> a...@effectivemachines.com>
> >>> wrote:
> >>>>
> >>>>   It’s no longer scheduling jobs.
> >>> Thanks Allen, looking into it. Also taking advantage of a required
> service
> >>> restart to upgrade 60 outdated plugins.
> >>>
> >>>>   Any clues as to why this happens?
> >>> Not currently.
> >>>
> >>> Gav…
> >>>
> >>>>
> >>>
> >
>
>


Re: Gradle on Jenkins

2017-11-10 Thread Ismael Juma
That works for Apache Kafka.

Thanks,
Ismael

On Fri, Nov 10, 2017 at 12:37 AM, Daniel Pono Takamori 
wrote:

> A ticket [0] recently came up about upgrading the Gradle version on
> our nodes.  It appears we have some nodes with gradle-2.14 and 3.1
> installed most places but not all.  As a measure of consolidation,
> we're going to provide legacy support for 3.1 (as in we won't remove
> it but won't be installing it in the future) and the latest 3.x and
> 4.x versions [1].
> This is a courtesy email asking for input on supporting older versions
> as well as alerting you to the deprecation of versions <2.  If you
> could let us know if you are still using version 2 that would be
> helpful so we can provide a subset of nodes for that support.
>
> Cheers,
> -Pono
>
>
> [0] - https://issues.apache.org/jira/browse/INFRA-15448
> [1] - https://cwiki.apache.org/confluence/display/INFRA/
> Gradle+Installations
>


Re: JDK 11 Early Access build 8 available

2018-04-12 Thread Ismael Juma
Hi Gavin,

I tried this and got the following error:

"*20:00:47* ERROR: JAVA_HOME is set to an invalid directory:
/home/jenkins/tools/java/jdk-11-ea+8"

https://builds.apache.org/job/kafka-trunk-jdk11/3/console

Ismael

On Thu, Apr 12, 2018 at 6:02 AM, Gavin McDonald 
wrote:

> Thanks Rory,
>
> I’ve added the Oracle JDK 11 ea 8 to our Jenkins and Buildbot nodes and is
> rolling out to them as we speak.
> I’ll do the same tomorrow for the OpenJDK version.
>
> Projects should start testing on this version ASAP.
>
> HTH
>
> Gav…
>
>
> > On 12 Apr 2018, at 7:42 pm, Rory O'Donnell 
> wrote:
> >
> >
> > Hi Mark & Gavin,
> >
> > **JDK 11 EA build 8, *under both the GPL and Oracle EA licenses, is
> now available at **http://jdk.java.net/11**. **
> > *
> >
> > * Newly approved Schedule, status & features
> > o http://openjdk.java.net/projects/jdk/11/
> > * Release Notes:
> > o http://jdk.java.net/11/release-notes
> > * Summary of changes
> > o https://download.java.net/java/early_access/jdk11/8/jdk-11+8.html
> >
> > *Notable changes in JDK 11 EA builds since last email:*
> >
> > * Build 8:
> > o If you have a library that uses the Selector API heavily then
> >   now would be a good time to test it out. [1]
> > * Build 7
> > o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and
> >   will be removed in a future release.
> > * Build 6:
> > o JDK-8193033 : remove terminally deprecated
> >   sun.misc.Unsafe.defineClass. Users should use the public
> >   replacement `java.lang.invoke.MethodHandles.Lookup.defineClass`
> >   which was added in Java SE 9. [2]
> >
> > **
> >
> >
> > *SURVEY: The HotSpot Serviceability Agent (SA) *[3]
> >
> > * If you have used, or have (support) processes that utilize the
> >   Serviceability Agent or related APIs, then we would definitely
> >   appreciate if you would complete this survey:
> >   https://www.surveymonkey.com/r/CF3MYDL
> >
> >
> > Regards,
> > Rory
> >
> > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/
> 004964.html
> > [2] https://docs.oracle.com/javase/9/docs/api/java/lang/
> invoke/MethodHandles.Lookup.html#defineClass-byte:A-
> > [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/
> 001052.html
> >
> > --
> > Rgds,Rory O'Donnell
> > Quality Engineering Manager
> > Oracle EMEA , Dublin, Ireland
> >
>
>


Re: JDK 11 tool on Jenkins

2018-07-01 Thread Ismael Juma
Thanks Gav. Would it be possible for Gradle 4.8.1 to be installed as well
(4.4 is currently the latest)? Otherwise, the `gradle` command fails in the
following way:

17:08:30 + /home/jenkins/tools/gradle/4.4/bin/gradle
17:08:31
17:08:31 FAILURE: Build failed with an exception.
17:08:31
17:08:31 * What went wrong:
17:08:31 Could not determine java version from '11-ea'.

Gradle 4.8.1 is also needed due to the recent Maven Central TLS 1.2
requirement. Otherwise gradle plugin downloads fail when executed with Java
7 in the following way:

Received fatal alert: protocol_version


Thanks,
Ismael


On Fri, Jun 29, 2018 at 2:05 PM Gav  wrote:

> All done. Please test.
>
> /home/jenkins/tools/java/jdk-11-ea+19/bin/java -version
> java version "11-ea" 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+19)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+19, mixed mode)
>
>
> On Fri, Jun 29, 2018 at 1:42 PM, Zoran Regvart  wrote:
>
> > Awesome, thanks  Gavin!
> >
> > zoran
> >
> > On Fri, Jun 29, 2018 at 12:04 PM, Gav  wrote:
> > > HI,
> > >
> > > On Fri, Jun 29, 2018 at 8:47 AM, Zoran Regvart 
> > wrote:
> > >
> > >> Hi,
> > >> is there a chance we can get the JDK 11 early access builds tools
> > >> defined on Jenkins?
> > >>
> > >
> > > Sure,
> > >
> > >
> > >> I saw from the Maven Jenkins pipeline scripts[1] that there might be a
> > >> `JDK 11 b8 (early access build)`, but that doesn't seem to work when
> > >> we try it for Camel[2].
> > >>
> > >
> > > Looks like you are configured for your build to look for b19 which we
> > have
> > > not
> > > installed yet, so it is suggesting you try b8 which it found.
> > >
> > > I have checked a few random nodes, and b8 works fine.
> > >
> > > gmcdonald@asf916:~$ /home/jenkins/tools/java/jdk-11-ea+8/bin/java
> > -version
> > > java version "11-ea" 2018-09-25
> > > Java(TM) SE Runtime Environment 18.9 (build 11-ea+8)
> > > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+8, mixed mode)
> > > gmcdonald@asf916:~$
> > >
> > >
> > >
> > >> Any chance on getting a `JDK 11 (latest)` tool definition like we have
> > >> for 1.8-10?
> > >>
> > >
> > > Yes I'll get the latest b19 on there hopefully today. and symlink it as
> > > latest.
> > >
> > >
> > >
> > >
> > >> Should I raise an INFRA issue for that?
> > >>
> > >
> > > Its something on our roadmap anyway so no need, I'll get it done
> > >
> > > Thanks
> > >
> > > Gav...
> > >
> > >
> > >> zoran
> > >>
> > >> [1] https://github.com/apache/maven-jenkins-env/blob/master/
> > >> vars/jenkinsEnv.groovy#L46
> > >> [2] https://builds.apache.org/view/C/view/Apache%20Camel/
> > >> job/Camel.daily/69/console
> > >> --
> > >> Zoran Regvart
> > >>
> >
> >
> >
> > --
> > Zoran Regvart
> >
>


Re: JDK 11 is now in Rampdown Phase one

2018-07-05 Thread Ismael Juma
FYI, the following regression (which has already been fixed and will
hopefully be in the next build) is affecting projects like Gradle and JUnit:

https://bugs.openjdk.java.net/browse/JDK-8206355

So, probably worth waiting for the next build.

Ismael

On Mon, Jul 2, 2018 at 2:01 AM Rory O'Donnell 
wrote:

> Hi Mark & Gavin,
>
> *JDK 11 is now in Rampdown Phase one***
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.We’ve forked the main-line source repository, jdk/jdk, to
> the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or
> jdk/client are now bound for JDK 12.
>
>   * For more details , see Mark Reinhold's email to jdk-dev mailing list
> [1]
>   * The Rampdown Phase one process  [2].
>
> *Note: -* Early-Access build archive format on Windows has changed to zip.
>
> Since our last email the following JEPs have been targeted to JDK 11 :
>
>   * 181: Nest-Based Access Control
>   * 315: Improve Aarch64 Intrinsics
>   * 330: Launch Single-File Source-Code Programs
>   * 331: Low-Overhead Heap Profiling
>   * 332: Transport Layer Security (TLS) 1.3
>   * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
>   * 335: *Deprecate the Nashorn JavaScript Engine*
>   * 336: *Deprecate the Pack200 Tools and API*
>
> Other important changes since last email:
>
> Build 19:
> JDK-8205043  : G1
> enables adaptive parallel reference processing by default
> Build 18:
> JDK-8196141  : Add
> GoDaddy root certificates
> JDK-8204243  :
> *remove Thread.destroy() and Thread.stop(Throwable)*
> JDK-8202088  :
> Japanese New Era Implementation
> Build 17:
> JDK-8189949  :
> Remove Baltimore Cybertrust Code Signing CA
> JDK-8191031  :
> Remove several Symantec Root CAs
> JDK-8072996  :
> Deprecate stream-based GSSContext methods
> Build 16:
> JDK-8191844  :
> Remove SECOM root
>
> Rgds, Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html
> [2] http://openjdk.java.net/projects/jdk/11/#Schedule
>


Re: Jenkins (builds.a.o) extended downtime - 2000 UTC Saturday July 21st 8-24 hours

2018-07-23 Thread Ismael Juma
Thanks for the improvement, very much welcome!

Ismael

On Sat, Jul 21, 2018 at 8:24 PM Chris Lambertus  wrote:

> This maintenance is complete.
>
> Jenkins has been migrated to a brand new 48 core machine with 128GB RAM
> and 3.5TB of NVMe storage. Initial testing looks good, and builds are
> proceeding as expected. We hope this will provide a significant improvement
> in user experience on the front-end, and increase the throughput of builds.
>
> Please note that the 3.5TB of NVMe is less than what the previous jenkins
> master had. It is critical that all projects aggressively trim their
> retained builds in order for this shared resource to continue to function
> optimally.
>
> -Chris
>
>
>
>
> On Jul 21, 2018, at 1:01 PM, Chris Lambertus  wrote:
>
> This maintenance window is beginning now.
>
> -Chris
>
>
> On Jul 16, 2018, at 7:33 PM, Chris Lambertus  wrote:
>
> All,
>
> At 2000 UTC Saturday July 21st, the builds.apache.org jenkins service
> will be shut down and migrated to a new machine. We hope this will resolve
> myriad performance issues and frequent need for restarts of the master.
>
> We anticipate the downtime will take 8 hours at the minimum, and could
> take up to 24 hours depending on contingencies.
>
>
> Despite the previous message regarding this migration, we will NOT be
> pruning the master workspaces prior to moving. Once the service has been
> migrated and vetted on the new hardware, we will re-address the disk space
> issues.
>
>
> -Chris
> ASF Infra
>
>
>
>
>


Re: JDK 11: First Release Candidate available

2018-08-25 Thread Ismael Juma
Thanks Rory. The latest build includes an important TLS fix that was
causing a number of Kafka unit tests to fail. It would be great for the
Apache Jenkins instance to be updated to include this build.

Thanks,
Ismael

On Fri, Aug 24, 2018 at 1:52 AM Rory O'Donnell 
wrote:

>
> Hi Mark & Gavin, **
>
> *JDK 11 build 28 is our first JDK 11 Release Candidate [1]
> *
>
>   * JDK 11 Early Access  build 28 is available at : - jdk.java.net/11/
>
> *FOSS fixes in recent builds.*
>
>   * Eclipse Jetty - JDK-8207177
>  (b27)
>   * Apache Tomcat   -JDK-8208642
> (b27)
>   * JBoss Netty - JDK-8207029
>  (b23),
> JDK-8208166  (b25)
>
> *JDK 12 Early Access build 8 is available at : - jdk.java.net/12/*
>
>   * Release Notes for JDK 12 [2]
>   * Changes in this build include
>   o JDK-8208350  -
> Disable all DES TLS cipher suites
>
> *OpenJFX Early-Access Build 24 is available at :-*
> *http://jdk.java.net/openjfx/*
>
>   * This library is delivered as a set of modules, along with the native
> code needed to run JavaFX, that can be run using a JDK 10
>  build or a JDK 11 EA
>  build.
>   * This build is intended to allow application developers and OpenJFX
> contributors to test their applications with an unbundled,
> standalone JavaFX library.
>
> Regards,
> Rory
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html
> 
> [2] http://jdk.java.net/12/release-notes
>
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


Re: [NOTICE] Jenkins GHPRB deprecated, please switch :)

2019-07-10 Thread Ismael Juma
Looks like it has. Apache Kafka PRs don't trigger Jenkins builds any
longer. :( I hope the conversion is smooth, will try it now.

Ismael

On Wed, Jul 10, 2019 at 3:33 PM Kenneth Knowles  wrote:

> Has this support already been removed?
>
> All of Beam's jobs use this plugin. They are generated using the job DSL,
> but we have not ported to the other plugin.
>
> Kenn
>
> On Wed, Jul 10, 2019 at 1:33 PM Daniel Gruno  wrote:
>
> > Hi folks,
> > as part of some cleanup and consolidation (essentially we don't want to
> > maintain two different plugins that do the same thing), we have removed
> > support for the old GitHub PR Builder on Jenkins, and are focusing on the
> > modern variant. If your build previously made use of the old one (It's
> > called "GitHub Pull Request Builder" in the job configuration), we ask
> that
> > you please switch to the newer one (called "Build pull requests to the
> > repository" in the same config). There should be no other changes, but if
> > your builds start acting up, do let infra know :).
> >
> > As an added bonus, you no longer need to contact infra about webhooks
> when
> > setting up PR builds for new repositories, it should just work(tm).
> >
> > With regards,
> > Daniel on behalf of ASF Infra.
> >
>


Re: [NOTICE] Jenkins GHPRB deprecated, please switch :)

2019-07-10 Thread Ismael Juma
Does this "modern" version provide a way to retest builds without pushing
additional commits? This is very useful when tests fail due to
environmental issues or if they're flaky. I can't seem to find mention of
it in the documentation. It would be a shame to lose this feature.

Ismael

On Wed, Jul 10, 2019 at 7:30 PM Ismael Juma  wrote:

> Looks like it has. Apache Kafka PRs don't trigger Jenkins builds any
> longer. :( I hope the conversion is smooth, will try it now.
>
> Ismael
>
> On Wed, Jul 10, 2019 at 3:33 PM Kenneth Knowles  wrote:
>
>> Has this support already been removed?
>>
>> All of Beam's jobs use this plugin. They are generated using the job DSL,
>> but we have not ported to the other plugin.
>>
>> Kenn
>>
>> On Wed, Jul 10, 2019 at 1:33 PM Daniel Gruno 
>> wrote:
>>
>> > Hi folks,
>> > as part of some cleanup and consolidation (essentially we don't want to
>> > maintain two different plugins that do the same thing), we have removed
>> > support for the old GitHub PR Builder on Jenkins, and are focusing on
>> the
>> > modern variant. If your build previously made use of the old one (It's
>> > called "GitHub Pull Request Builder" in the job configuration), we ask
>> that
>> > you please switch to the newer one (called "Build pull requests to the
>> > repository" in the same config). There should be no other changes, but
>> if
>> > your builds start acting up, do let infra know :).
>> >
>> > As an added bonus, you no longer need to contact infra about webhooks
>> when
>> > setting up PR builds for new repositories, it should just work(tm).
>> >
>> > With regards,
>> > Daniel on behalf of ASF Infra.
>> >
>>
>


Re: [NOTICE] Jenkins GHPRB deprecated, please switch :)

2019-07-10 Thread Ismael Juma
Hi,

A couple more issues:

1. If you configure multiple Jenkins jobs (eg one for Java 8 and one for
Java 11), only 1 seems to update the commit status in the PR. The previous
plugin was able to show the status for multiple jobs.
2. It's unclear how to enable a job for certain branches only. With the
previous plugin, we could configure the Java 11 job to only trigger for the
branches where Java 11 is supported.

Am I missing something or is the "modern" plugin not a suitable
replacement? Would you consider restoring the previous plugin?

Thanks,
Ismael

On Wed, Jul 10, 2019 at 7:40 PM Ismael Juma  wrote:

> Does this "modern" version provide a way to retest builds without pushing
> additional commits? This is very useful when tests fail due to
> environmental issues or if they're flaky. I can't seem to find mention of
> it in the documentation. It would be a shame to lose this feature.
>
> Ismael
>
> On Wed, Jul 10, 2019 at 7:30 PM Ismael Juma  wrote:
>
>> Looks like it has. Apache Kafka PRs don't trigger Jenkins builds any
>> longer. :( I hope the conversion is smooth, will try it now.
>>
>> Ismael
>>
>> On Wed, Jul 10, 2019 at 3:33 PM Kenneth Knowles  wrote:
>>
>>> Has this support already been removed?
>>>
>>> All of Beam's jobs use this plugin. They are generated using the job DSL,
>>> but we have not ported to the other plugin.
>>>
>>> Kenn
>>>
>>> On Wed, Jul 10, 2019 at 1:33 PM Daniel Gruno 
>>> wrote:
>>>
>>> > Hi folks,
>>> > as part of some cleanup and consolidation (essentially we don't want to
>>> > maintain two different plugins that do the same thing), we have removed
>>> > support for the old GitHub PR Builder on Jenkins, and are focusing on
>>> the
>>> > modern variant. If your build previously made use of the old one (It's
>>> > called "GitHub Pull Request Builder" in the job configuration), we ask
>>> that
>>> > you please switch to the newer one (called "Build pull requests to the
>>> > repository" in the same config). There should be no other changes, but
>>> if
>>> > your builds start acting up, do let infra know :).
>>> >
>>> > As an added bonus, you no longer need to contact infra about webhooks
>>> when
>>> > setting up PR builds for new repositories, it should just work(tm).
>>> >
>>> > With regards,
>>> > Daniel on behalf of ASF Infra.
>>> >
>>>
>>


Re: [NOTICE] Jenkins GHPRB deprecated, please switch :)

2019-07-11 Thread Ismael Juma
Thank you Daniel!

Ismael

On Thu, Jul 11, 2019 at 12:21 AM Daniel Gruno  wrote:

> As there has been quite a bit of unforeseen trouble here, we have added
> the old plugin back in, while we evaluate how to best switch (or whether to
> stick with the GHPRB instead). Needless to say, there is some conflicting
> documentation we need to look at one more time.
>
> On 2019/07/11 03:14:17, Ismael Juma  wrote:
> > Hi,
> >
> > A couple more issues:
> >
> > 1. If you configure multiple Jenkins jobs (eg one for Java 8 and one for
> > Java 11), only 1 seems to update the commit status in the PR. The
> previous
> > plugin was able to show the status for multiple jobs.
> > 2. It's unclear how to enable a job for certain branches only. With the
> > previous plugin, we could configure the Java 11 job to only trigger for
> the
> > branches where Java 11 is supported.
> >
> > Am I missing something or is the "modern" plugin not a suitable
> > replacement? Would you consider restoring the previous plugin?
> >
> > Thanks,
> > Ismael
> >
> > On Wed, Jul 10, 2019 at 7:40 PM Ismael Juma  wrote:
> >
> > > Does this "modern" version provide a way to retest builds without
> pushing
> > > additional commits? This is very useful when tests fail due to
> > > environmental issues or if they're flaky. I can't seem to find mention
> of
> > > it in the documentation. It would be a shame to lose this feature.
> > >
> > > Ismael
> > >
> > > On Wed, Jul 10, 2019 at 7:30 PM Ismael Juma  wrote:
> > >
> > >> Looks like it has. Apache Kafka PRs don't trigger Jenkins builds any
> > >> longer. :( I hope the conversion is smooth, will try it now.
> > >>
> > >> Ismael
> > >>
> > >> On Wed, Jul 10, 2019 at 3:33 PM Kenneth Knowles 
> wrote:
> > >>
> > >>> Has this support already been removed?
> > >>>
> > >>> All of Beam's jobs use this plugin. They are generated using the job
> DSL,
> > >>> but we have not ported to the other plugin.
> > >>>
> > >>> Kenn
> > >>>
> > >>> On Wed, Jul 10, 2019 at 1:33 PM Daniel Gruno 
> > >>> wrote:
> > >>>
> > >>> > Hi folks,
> > >>> > as part of some cleanup and consolidation (essentially we don't
> want to
> > >>> > maintain two different plugins that do the same thing), we have
> removed
> > >>> > support for the old GitHub PR Builder on Jenkins, and are focusing
> on
> > >>> the
> > >>> > modern variant. If your build previously made use of the old one
> (It's
> > >>> > called "GitHub Pull Request Builder" in the job configuration), we
> ask
> > >>> that
> > >>> > you please switch to the newer one (called "Build pull requests to
> the
> > >>> > repository" in the same config). There should be no other changes,
> but
> > >>> if
> > >>> > your builds start acting up, do let infra know :).
> > >>> >
> > >>> > As an added bonus, you no longer need to contact infra about
> webhooks
> > >>> when
> > >>> > setting up PR builds for new repositories, it should just work(tm).
> > >>> >
> > >>> > With regards,
> > >>> > Daniel on behalf of ASF Infra.
> > >>> >
> > >>>
> > >>
> >
>


Re: broken builds taking up resources

2020-01-28 Thread Ismael Juma
FYI, Apache Kafka builds take 3 to 4 hours to run currently (build, unit
and integration tests).

Thanks,
Ismael

On Wed, Jan 22, 2020 at 4:55 PM Chris Lambertus  wrote:

> Folks,
>
> Over the last week or so we have received many reports of broken builds
> due to nodes out of resources. As noted in INFRA-19751, builds appear to
> fail yet continue to run, using up all available resources on a build node.
>
> I will be implementing a system to kill jenkins processes based on
> duration of run. My initial feeling is to kill any single process which has
> been running for longer than one hour real-time.
>
> I will also be implementing a system to kill/purge all docker containers
> which have been running for over 6 hours.
>
>
> I am seeking input on these time limits, especially from those with larger
> builds. Is there any reason a -single process- or a docker container should
> run for more than 1 or 6 hours respectively?
>
> Thanks,
> Chris
> ASF Infra
>
>


Re: [IMPORTANT] - Migration to ci-builds.a.o

2020-08-05 Thread Ismael Juma
Hi,

Can you please create a folder for Kafka?

Ismael

On Thu, Jul 16, 2020 at 9:33 AM Gavin McDonald  wrote:

> Hi All,
>
> This NOTICE is for everyone on builds.apache.org. We are migrating to a
> new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
>
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
>
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
>
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
>
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
>
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
>
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
>
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
>
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
>
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
>
> Lets get going ...
>
> --
>
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>


Re: [IMPORTANT] - Migration to ci-builds.a.o

2020-08-05 Thread Ismael Juma
Sorry, forgot to mention that all Kafka committers should have edit access
to the folder.

Ismael

On Wed, Aug 5, 2020 at 8:16 PM Ismael Juma  wrote:

> Hi,
>
> Can you please create a folder for Kafka?
>
> Ismael
>
> On Thu, Jul 16, 2020 at 9:33 AM Gavin McDonald 
> wrote:
>
>> Hi All,
>>
>> This NOTICE is for everyone on builds.apache.org. We are migrating to a
>> new
>> Cloudbees based Client Master called https://ci-builds.apache.org. The
>> migrations of all jobs needs to be done before the switch off date of 15th
>> August 2020, so you have a maximum of 4 weeks.
>>
>> There is no tool or automated way of migrating your jobs, the
>> differences in the platforms, the plugins and the setup makes it
>> impossible
>> to do in a safe way. So, you all need to start creating new jobs on
>> ci-infra.a.o and then , when you are happy, turn off your old builds on
>> builds.a.o.
>>
>> There are currently 4 agents over there ready to take jobs, plus a
>> floating
>> agent which is shared amongst many masters (more to come). I will migrate
>> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
>> will keep an eye of load across both and adjust accordingly.
>>
>> If needed, create a ticket on INFRA jira for any issues that crop up, or
>> email here on builds@a.o. there may be one or two plugins we need to
>> install/tweak etc.
>>
>> We will be not using 'Views' at the top level, but rather we will take
>> advantage of 'Folders Plus' - each project will get its own Folder and
>> have
>> authorisation access to create/edit jobs etc within that folder. I will
>> create these folders as you ask for them to start with. This setup allows
>> for credentials isolation amongst other benefits, including but not
>> limited
>> to exclusive agents (Controlled Agents) for your own use , should you have
>> any project targeted donations of agents.
>>
>> As with other aspects of the ASF, projects can choose to just enable all
>> committers access to their folder, just ask.
>>
>> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
>> be setting up any forwarding rules or anything like that.
>>
>> So, please, get started *now *on this so you can be sure we are all
>> completed before the final cutoff date of 15th August 2020.
>>
>> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
>> tickets.
>>
>> Hadoop and related projects have their own migration path to follow, same
>> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
>> very well in their new homes.
>>
>> Lets get going ...
>>
>> --
>>
>> *Gavin McDonald*
>> Systems Administrator
>> ASF Infrastructure Team
>>
>


Re: [ci-infra] - Plugin Installations

2020-08-11 Thread Ismael Juma
Hi Gavin,

Apache Kafka uses "GitHub Pull Request Builder" for its PR builds. Would it
be possible to install this plugin? I migrated several jobs to the new CI
server and this plugin is all I need to complete the migration.

Thanks,
Ismael

On Sat, Jul 18, 2020 at 3:09 AM Gavin McDonald  wrote:

> Hi All,
>
> The other thread is getting a bit large, lets try and stop posting there.
>
> For new plugin installation requests please either file an INFRA Jira
> ticket or reply to this new thread.
>
> Over the next couple of weeks, I will ensure plugins get installed timely
> so you can continue testing the new system and getting your jobs
> to work.
>
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>


Re: GitHub Pull Request Builder - Deprecated

2020-08-14 Thread Ismael Juma
Hi Gavin,

Do these plugins (`2` and `3`) allow multiple pull request builders to be
configured? I couldn't find it in the documentation. This would be a
significant regression for Apache Kafka, unfortunately. Is there a
possibility that we install `1` with a plan to remove in 3-6 months? That
would give projects a bit of time to figure out how to migrate without
causing major disruption to the existing flow.

Ismael

On Fri, Aug 14, 2020 at 12:31 AM Gavin McDonald 
wrote:

> Hi All,
>
> For those of you that used the specific "GitHub Pull Request Builder" on
> builds.a.o ,
> we will not be installing it on the ci-builds.a.o.
>
> The plugin deprecated and unmaintained [1] and it is recommended to move to
> one of
> the other GH plugins we have installed [2] and [3].
>
> If you need help migrating to these other plugins, please post a new
> message here
> and have others here help you with it.
>
> Thank You.
>
> [1] - https://plugins.jenkins.io/ghprb/
> [2] -
>
> https://docs.cloudbees.com/docs/cloudbees-ci/latest/cloud-admin-guide/github-branch-source-plugin
>
> [3] -
>
> https://docs.cloudbees.com/docs/admin-resources/latest/plugins/pull-request-builder-for-github#pull-request-builder-for-github-usage
>
>
>
> --
>
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>


Re: [JENKINS] - Scheduled automatic plugin upgrades

2021-06-13 Thread Ismael Juma
Hi Gavin,

This is great, thanks!

I noticed a few jobs that timed out, but the abort didn't work for some
reason (as you guessed it may happen). I force killed the Kafka ones, but
there were 2 others remaining (I don't have permission to force kill those).

Ismael

On Sun, Jun 13, 2021, 1:52 AM Gavin McDonald  wrote:

> Hi All,
>
> Starting today, All Jenkins Client Controllers will perform
> automated plugin upgrades. After which it will wait for in progress
> builds to complete before restarting the service to apply those
> upgrades.
>
> The only thing that I can see that would upset this process are
> stuck jobs, so I will be keeping an eye out and kill any job
> holding up progress.
>
> Sunday is traditionally the quietest day for builds. However, cronned
> jobs like nightlies would still run. Projects can help out by avoiding
> Sundays if possible, but it is not a requirement.
>
> I will keep an on how many plugins get upgraded over the next few
> Sundays and if appropriate we could then change this to a monthly
> job instead.
>
> HTH
>
> --
>
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team
>


Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up

2023-10-20 Thread Ismael Juma
Hi David,

> so may I ask you to send me a brief email with the Java 21 support status
of your project(s): Already supported - Plan to support short-term - Don't
plan to support short-term ?

Apache Kafka: Java 21 is supported in trunk and will be part of the
upcoming 3.7.0 release.

Thanks,
Ismael

On Fri, Oct 20, 2023 at 2:37 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> JDK 21 has been released (General Availability) on September 19th as
> planned. You can find "The Arrival of Java 21" announcement here [1], and
> some additional Java 21 materials in the "Topics of Interest" section
> below. On behalf of the entire Java team, let me send our thanks to all of
> you. Through your active participation in this program, you are helping
> shape the Java platform!
>
> Needless to say, that Java 21 is an important release, so may I ask you to
> send me a brief email with the Java 21 support status of your project(s):
> Already supported - Plan to support short-term - Don't plan to support
> short-term ?
>
> And now that JDK 21 is out, let's shift our attention to JDK 22 which will
> enter the Rampdown Phase in less than 50 days on December 7 [2].
>
> I want to conclude this update by briefly mentioning three different
> initiatives to are relevant to this group as they are, in their own way and
> at various levels, contributing to adopt newer Java releases more rapidly:
> the Class-File API, Oracle's Java Platform extension for VS Code, and the
> Java Playground.
>
> ### The Class-File API
>
> The Class-File API is a new standard API for parsing, generating, and
> transforming Java class files. One of its unique aspects is that it will
> co-evolve with the class-file format, which overtime will greatly reduce
> the friction of implementing new class-file features. With the fast-paced
> evolution of the Java platform, this was much-needed. This API should soon
> be previewed and as it matures, we expect the JDK to switch from using
> various custom class-file libraries to this standard API. We also expect
> that overtime frameworks relying on bytecode manipulation will also benefit
> from using this new JDK class-file library. For more information, please
> check this recent Newscast [3] for an overview, Brian Goetz's JVMLS session
> [4] for more details and design considerations, and JEP 457: Class-File API
> (Preview) [5] for the technical details.
>
> ### Oracle's Java Platform extension for Visual Studio Code
>
> Oracle has just announced [6] a new Visual Studio Code extension for Java
> developers. Unlike other VS Code extensions, this new extension is using
> under the hood the `javac` compiler for code editing and compilation, and
> OpenJDK's debugger interface for debugging. This enables us to offer VS
> Code IDE support for new JDK features as soon as they are introduced, even
> during JDK Early Access phases. To this effect, this VS Code Extension will
> support the current JDK releases as well as the next upcoming JDK version.
> For more information, please check the announcement [6].
>
> ### The Java Playground
>
> The Java Playground [7] is an online sandbox that helps testing and
> exploring new Java language features. No setup required, just type your
> Java snippet in your browser and run it! Right now, the Playground is using
> Java 21 with Preview Features enabled, and it will switch to a new Java
> version as soon as there is a new Java language features integrated in
> OpenJDK Early-Access builds. The Playground is focusing mostly on Project
> Amber and is certainly not mean to be some sort of a lightweight
> online-IDE, it is instead a learning tool to play with new Java language
> feature shortly after they have been integrated into the platform.
>
> [1] https://inside.java/2023/09/19/the-arrival-of-java-21/
> [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html
> [3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks
> [4] https://www.youtube.com/watch?v=pcg-E_qyMOI
> [5] https://openjdk.org/jeps/457
> [6] https://inside.java/2023/10/18/announcing-vscode-extension/
> [7] https://dev.java/playground
>
>
> ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
>
> As discussed in the July 2023 Quality Outreach update [8], starting in JDK
> 21 javac emits a note if _implicit_ annotation processing is being used,
> that is, if one or more annotation processors are found and run from the
> class path when no explicit annotation processing configuration options are
> used.
>
> The note is reported since, quoting from the note text: "A future release
> of javac may disable annotation processing unless at least one processor is
> specified by name (-processor), or a search path is specified
> (--processor-path, --processor-module-path), or annotation processing is
> enabled explicitly (-proc:only, -proc:full)."
>
> That future version of javac has arrived in JDK 22 b19+ with JDK-8306819
> ("Consider disabling the compiler's default active a

Triggering CI rebuilds for GitHub pull requests

2015-07-20 Thread Ismael Juma
Hi,

At Kafka, we intend to change our contribution flow to be based on GitHub
pull requests. An important part of this flow is running CI builds on pull
requests. The basics are now working[1] thanks to Andrew Bayer's help. I
have a few questions that I could not find an answer for (if this is
information is already available somewhere, a reference is appreciated) and
I was hoping that someone here could help:

   1. Is it possible to trigger a rebuild with "retest this please"?
   2. Who is allowed to trigger a rebuild? Is it any committer or only
   those with access to Jenkins?
   3. Can we use "add to whitelist" to add another user to the authorised
   list?
   4. Out of curiosity, are we using
   
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
   or something custom?

Normally, I would just figure it out by trying these things, but I am not a
committer and I don't have access to Jenkins, which makes things a bit
harder!

Thanks,
Ismael

[1] https://builds.apache.org/job/kafka-trunk-git-pr/


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-22 Thread Ismael Juma
Hi,

Any feedback on the below? "retest this please" did not seem to work when a
committer tried it.

On Mon, Jul 20, 2015 at 4:15 PM, Ismael Juma  wrote:

> Hi,
>
> At Kafka, we intend to change our contribution flow to be based on GitHub
> pull requests. An important part of this flow is running CI builds on pull
> requests. The basics are now working[1] thanks to Andrew Bayer's help. I
> have a few questions that I could not find an answer for (if this is
> information is already available somewhere, a reference is appreciated) and
> I was hoping that someone here could help:
>
>1. Is it possible to trigger a rebuild with "retest this please"?
>2. Who is allowed to trigger a rebuild? Is it any committer or only
>those with access to Jenkins?
>3. Can we use "add to whitelist" to add another user to the authorised
>list?
>4. Out of curiosity, are we using
>
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
>or something custom?
>
> Normally, I would just figure it out by trying these things, but I am not
> a committer and I don't have access to Jenkins, which makes things a bit
> harder!
>
> Thanks,
> Ismael
>
> [1] https://builds.apache.org/job/kafka-trunk-git-pr/
>


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-23 Thread Ismael Juma
On Wed, Jul 22, 2015 at 5:46 PM, Andrew Bayer 
wrote:

> I think it only triggers on changes to the pull request - i.e., a new
> commit. I'll talk to the cloudbees people (we are using the Jenkins
> Enterprise GH PR plugin, not the open source one) and see if they have any
> ideas.
>

Thank you Andrew. Hopefully they have some ideas as it's quite important to
be able to rerun builds (in an ideal there would be no flaky tests, but...).

It would be surprising if the enterprise version was unable to do something
that the open-source version supported from day one.

Best,
Ismael


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-23 Thread Ismael Juma
On Thu, Jul 23, 2015 at 9:36 AM, Andrew Bayer 
wrote:

> At the time I set us up with the plugin, the OSS one required a lot more
> privileges on the Github side than we are able to give it. I'll check to
> see if it's any more reasonable now. =)
>

I see, that makes sense. Spark seems to use the open-source plugin with the
AMPLab Jenkins instance:

https://github.com/apache/spark/pull/7613
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/38199/consoleFull

Not sure how they do that, but that would imply that there are enough
permissions in the GitHub side (or they're doing something they shouldn't).

In the context of Kafka, Confluent offered their Jenkins instance, but my
preference would be to get it to work with Apache's (if possible).

Best,
Ismael


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-23 Thread Ismael Juma
On Thu, Jul 23, 2015 at 10:20 AM, Andrew Bayer 
wrote:

> I'll find a way. =)
>

Excellent, thanks. :)

Ismael


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-28 Thread Ismael Juma
Hi Andrew,

Did you have a chance to look into this? As the number of people using pull
requests in Kafka increases, it becomes more important to have a solution
for this. Even if the actual solution may not be available immediately, it
would still be good to know if there will be one.

Thanks for your help.

Best,
Ismael

On Thu, Jul 23, 2015 at 10:20 AM, Andrew Bayer 
wrote:

> I'll find a way. =)
> On Jul 23, 2015 11:19, "Ismael Juma"  wrote:
>
> > On Thu, Jul 23, 2015 at 9:36 AM, Andrew Bayer 
> > wrote:
> >
> > > At the time I set us up with the plugin, the OSS one required a lot
> more
> > > privileges on the Github side than we are able to give it. I'll check
> to
> > > see if it's any more reasonable now. =)
> > >
> >
> > I see, that makes sense. Spark seems to use the open-source plugin with
> the
> > AMPLab Jenkins instance:
> >
> > https://github.com/apache/spark/pull/7613
> >
> >
> https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/38199/consoleFull
> >
> > Not sure how they do that, but that would imply that there are enough
> > permissions in the GitHub side (or they're doing something they
> shouldn't).
> >
> > In the context of Kafka, Confluent offered their Jenkins instance, but my
> > preference would be to get it to work with Apache's (if possible).
> >
> > Best,
> > Ismael
> >
>


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-28 Thread Ismael Juma
On Tue, Jul 28, 2015 at 2:14 PM, Andrew Bayer 
wrote:

> I have not yet - sorry.
>

Thanks anyway. :) Should I file a JIRA ticket for this feature request?

Ismael


Re: Triggering CI rebuilds for GitHub pull requests

2015-07-29 Thread Ismael Juma
On Tue, Jul 28, 2015 at 3:01 PM, Andrew Bayer 
wrote:

> Yes, please. =)
>

Here it is:

https://issues.apache.org/jira/browse/BUILDS-102

Best,
Ismael


[jira] [Created] (BUILDS-97) Kafka Jenkins job not triggered by GitHub pull request

2015-07-16 Thread Ismael Juma (JIRA)
Ismael Juma created BUILDS-97:
-

 Summary: Kafka Jenkins job not triggered by GitHub pull request
 Key: BUILDS-97
 URL: https://issues.apache.org/jira/browse/BUILDS-97
 Project: Infra Build Platform
  Issue Type: Task
Reporter: Ismael Juma


Jun Rao has created a Jenkins job for building GitHub pull requests (as per 
instructions in the [blog 
post|https://blogs.apache.org/infra/entry/github_pull_request_builds_now]):

https://builds.apache.org/view/All/job/kafka-trunk-git-pr/

It doesn't seem to be working. I have just created a pull request and no build 
is triggered:

https://github.com/apache/kafka/pull/81

Note that the two existing builds in the Jenkins job are normal builds from 
trunk, not pull request builds.

I was told in HipChat that "PRs automatically trigger a call to 
builds.apache.org for kafka already".

Would we be able to get some assistance on this? It may very well be user 
error, but Jun hasn't been able to figure out and I don't have access to 
Jenkins. Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (BUILDS-97) Kafka Jenkins job not triggered by GitHub pull request

2015-07-16 Thread Ismael Juma (JIRA)

[ 
https://issues.apache.org/jira/browse/BUILDS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629786#comment-14629786
 ] 

Ismael Juma commented on BUILDS-97:
---

Thank you very much and sorry about that.

> Kafka Jenkins job not triggered by GitHub pull request
> --
>
> Key: BUILDS-97
> URL: https://issues.apache.org/jira/browse/BUILDS-97
> Project: Infra Build Platform
>  Issue Type: Task
>    Reporter: Ismael Juma
>Assignee: Andrew Bayer
>
> Jun Rao has created a Jenkins job for building GitHub pull requests (as per 
> instructions in the [blog 
> post|https://blogs.apache.org/infra/entry/github_pull_request_builds_now]):
> https://builds.apache.org/view/All/job/kafka-trunk-git-pr/
> It doesn't seem to be working. I have just created a pull request and no 
> build is triggered:
> https://github.com/apache/kafka/pull/81
> Note that the two existing builds in the Jenkins job are normal builds from 
> trunk, not pull request builds.
> I was told in HipChat that "PRs automatically trigger a call to 
> builds.apache.org for kafka already".
> Would we be able to get some assistance on this? It may very well be user 
> error, but Jun hasn't been able to figure out and I don't have access to 
> Jenkins. Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (BUILDS-99) Working copy in kafka Jenkins PR job needs merge

2015-07-20 Thread Ismael Juma (JIRA)
Ismael Juma created BUILDS-99:
-

 Summary: Working copy in kafka Jenkins PR job needs merge
 Key: BUILDS-99
 URL: https://issues.apache.org/jira/browse/BUILDS-99
 Project: Infra Build Platform
  Issue Type: Task
Reporter: Ismael Juma


All builds are failing because the working copy has an unresolved conflict. For 
example:

https://builds.apache.org/job/kafka-trunk-git-pr/18/

It would be good to fix the working copy, but even better would be to change 
the config so that this kind of issue doesn't happen again (if possible).

It seems like this issue was triggered by this pull request that tries to merge 
`trunk` into `0.8.1`:

https://github.com/apache/kafka/pull/42

Seems like an accidental pull request. We can't close it and the author is 
unresponsive. Any chance you can close it? Or do I need to file a separate 
INFRA issue for that?

Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (BUILDS-99) Working copy in kafka Jenkins PR job needs merge

2015-07-20 Thread Ismael Juma (JIRA)

[ 
https://issues.apache.org/jira/browse/BUILDS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633633#comment-14633633
 ] 

Ismael Juma commented on BUILDS-99:
---

Awesome. Thanks so much for the fast reaction. :)

> Working copy in kafka Jenkins PR job needs merge
> 
>
> Key: BUILDS-99
> URL: https://issues.apache.org/jira/browse/BUILDS-99
> Project: Infra Build Platform
>  Issue Type: Task
>    Reporter: Ismael Juma
>Assignee: Andrew Bayer
>
> All builds are failing because the working copy has an unresolved conflict. 
> For example:
> https://builds.apache.org/job/kafka-trunk-git-pr/18/
> It would be good to fix the working copy, but even better would be to change 
> the config so that this kind of issue doesn't happen again (if possible).
> It seems like this issue was triggered by this pull request that tries to 
> merge `trunk` into `0.8.1`:
> https://github.com/apache/kafka/pull/42
> Seems like an accidental pull request. We can't close it and the author is 
> unresponsive. Any chance you can close it? Or do I need to file a separate 
> INFRA issue for that?
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (BUILDS-102) Ability to trigger Jenkins rebuild for GitHub pull requests

2015-07-29 Thread Ismael Juma (JIRA)
Ismael Juma created BUILDS-102:
--

 Summary: Ability to trigger Jenkins rebuild for GitHub pull 
requests
 Key: BUILDS-102
 URL: https://issues.apache.org/jira/browse/BUILDS-102
 Project: Infra Build Platform
  Issue Type: Improvement
  Components: Jenkins
Reporter: Ismael Juma


It would be really useful to be able to trigger a Jenkins rebuild for a GitHub 
pull request when the build fails due to a transient problem (ie flaky tests 
and/or environmental issues). Despite our best efforts, it's hard to eliminate 
all flaky tests from the Kafka codebase (as some are fixed, new ones appear).

This is supported by the open-source GitHub Pull Request Builder Plugin via 
comments in the pull request itself (e.g. "retest this please" to rebuild, "add 
to whitelist" to automatically build future pull requests from the submitter, 
etc.):

https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin

Spark is using this with the AMPLab Jenkins instance:
https://github.com/apache/spark/pull/7613
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/38199/consoleFull

The Apache Jenkins instance is using the Jenkins Enterprise GH PR plugin, which 
doesn't support this functionality (probably based on 
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) because the more 
featured one required privileges on the GitHub side that the Apache Infra team 
was not able to give at the time (as explained by [~abayer]).

[~abayer] suggested that he would check if things have changed. The fact that 
Spark made it work is a good indicator. We also have the option of moving to a 
separate Jenkins instance (Confluent has offered theirs), but we would prefer 
to improve the Apache one as that benefits the other projects too.

This was originally discussed in the following thread in the mailing list:

https://mail-archives.apache.org/mod_mbox/www-builds/201507.mbox/%3CCAD5tkZYrrjp4%2BS7a7DBNMZsAXJozB8kopwgGC%3DOLO63aB-4mBg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (BUILDS-102) Ability to trigger Jenkins rebuild for GitHub pull requests

2015-07-29 Thread Ismael Juma (JIRA)

[ 
https://issues.apache.org/jira/browse/BUILDS-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645889#comment-14645889
 ] 

Ismael Juma commented on BUILDS-102:


That sounds promising [~abayer]. Thanks for looking into this.

In the meantime, I'll test close/reopen PR as a workaround.

> Ability to trigger Jenkins rebuild for GitHub pull requests
> ---
>
> Key: BUILDS-102
> URL: https://issues.apache.org/jira/browse/BUILDS-102
> Project: Infra Build Platform
>  Issue Type: Improvement
>  Components: Jenkins
>Reporter: Ismael Juma
>Assignee: Andrew Bayer
>
> It would be really useful to be able to trigger a Jenkins rebuild for a 
> GitHub pull request when the build fails due to a transient problem (ie flaky 
> tests and/or environmental issues). Despite our best efforts, it's hard to 
> eliminate all flaky tests from the Kafka codebase (as some are fixed, new 
> ones appear).
> This is supported by the open-source GitHub Pull Request Builder Plugin via 
> comments in the pull request itself (e.g. "retest this please" to rebuild, 
> "add to whitelist" to automatically build future pull requests from the 
> submitter, etc.):
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
> Spark is using this with the AMPLab Jenkins instance:
> https://github.com/apache/spark/pull/7613
> https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/38199/consoleFull
> The Apache Jenkins instance is using the Jenkins Enterprise GH PR plugin, 
> which doesn't support this functionality (probably based on 
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) because the more 
> featured one required privileges on the GitHub side that the Apache Infra 
> team was not able to give at the time (as explained by [~abayer]).
> [~abayer] suggested that he would check if things have changed. The fact that 
> Spark made it work is a good indicator. We also have the option of moving to 
> a separate Jenkins instance (Confluent has offered theirs), but we would 
> prefer to improve the Apache one as that benefits the other projects too.
> This was originally discussed in the following thread in the mailing list:
> https://mail-archives.apache.org/mod_mbox/www-builds/201507.mbox/%3CCAD5tkZYrrjp4%2BS7a7DBNMZsAXJozB8kopwgGC%3DOLO63aB-4mBg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (BUILDS-78) Creation of a Windows CI build agent for TeamCity

2015-08-02 Thread Ismael Juma (JIRA)

[ 
https://issues.apache.org/jira/browse/BUILDS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651262#comment-14651262
 ] 

Ismael Juma commented on BUILDS-78:
---

Kafka has recently set-up a Jenkins Job for GitHub pull requests:

https://builds.apache.org/job/kafka-trunk-git-pr/

> Creation of a Windows CI build agent for TeamCity
> -
>
> Key: BUILDS-78
> URL: https://issues.apache.org/jira/browse/BUILDS-78
> Project: Infra Build Platform
>  Issue Type: Task
>  Components: Jenkins
>Reporter: Paul King
>Assignee: Gavin
>Priority: Minor
>
> Groovy currently has a TeamCity CI server[1] (sponsored by JetBrains). It 
> performs builds of the codebase whenever changes are committed or pull 
> requests (PRs) are made on github. It runs on a linux server and supports 
> numerous JVM versions which are tested across the different Groovy branches. 
> We would like to add an additional build agent (a windows OS agent) into the 
> CI mix as well. Perhaps there is an INFRA box available that meets the 
> necessary criteria[2] that we could use for this purpose? Is this possible?
> [1] http://ci.groovy-lang.org/?guest=1 
> [2] 
> https://confluence.jetbrains.com/display/TCD8/Setting+up+and+Running+Additional+Build+Agents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)