Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
From: Knut Anders Hatlen <knut.hatlen@oracle.com>
To: <derby-dev@db.apache.org>
Subject: Re: fiixing JaCoCo, was: need help configuring Jenkins
References: <6e9248b3-2460-3805-3b24-7146353ad284@gmail.com>
	<CANi-yg82CnJhF6N1nYJOTRzqqkfPO6S5zzrD6tvhBxMM5wdKNA@mail.gmail.com>
	<CANi-yg_ntnhRaXmbMU36G6dWawaP0x28G4=HzZ1RSQDyeky+zg@mail.gmail.com>
	<CANi-yg9-K2Pwgjb+Wzsf6cn6DDn7RDKOUoxjTpexLfUkrxGZJw@mail.gmail.com>
	<386e53c8-d6d2-5463-e349-571c95d519dd@gmail.com>
	<CANi-yg-Rwk94BmO1GQkPx2WgxUFzV2PEc1ZpEQg6uzcEKnHXWQ@mail.gmail.com>
	<fe4139bb-b285-1868-0728-0ee355a7cdfb@gmail.com>
	<b770a96e-613d-81dc-09db-5a43e841ee4d@gmail.com>
	<565434e6-d545-50dd-ed2c-9344753ce561@gmail.com>
	<wjo8wp2ir8ta.fsf@oracle.com>
	<767ca96b-200a-2641-3b6e-c193a09fbc2f@gmail.com>
	<wjo860a1qtql.fsf@oracle.com>
Date: Thu, 23 Nov 2017 12:39:56 +0100
In-Reply-To: <wjo860a1qtql.fsf@oracle.com> (Knut Anders Hatlen's message of
	"Thu, 23 Nov 2017 09:33:54 +0100")
Message-ID: <wjo8zi7dp6k3.fsf@oracle.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
archived-at: Thu, 23 Nov 2017 11:40:18 -0000

Knut Anders Hatlen <knut.hatlen@oracle.com> writes:

> Rick Hillegas <rick.hillegas@gmail.com> writes:
>
>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas <rick.hillegas@gmail.com> writes:
>>>
>>>> I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
>>>> JaCoCo jars at
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
>>>> Let's see if that helps.
>>>>
>>>> Does anyone know why we also have a Derby-JaCoCo job (also broken)?
>>>> Why are we running JaCoCo twice and with different scripts?
>>> Hi Rick,
>>>
>>> I did some maintenance on the Derby-JaCoCo job some years ago, after it
>>> had broken when we had moved to a newer Java version which was not
>>> supported by the JaCoCo version we were using.
>>>
>>> I remember that we had two jobs at that time too. Don't know why we had
>>> two, though. I left the Derby-trunk-JaCoCo job alone, because it
>>> appeared to be abandoned (it was disabled, I think), and also because it
>>> fetched jar files from a committer's home directory. The Derby-JaCoCo
>>> job fetched the jar files from Maven, which sounded more maintainable as
>>> it allowed others than that one committer to make updates, if required.
>>>
>>> I was actually planning to delete the Derby-trunk-JaCoCo job after a
>>> while if the Derby-JaCoCo proved to be stable. But apparently I forgot.
>> Thanks, Knut. Sounds like we should retire Derby-trunk-JaCoCo and
>> figure out how to get Derby-JaCoCo to fetch the correct version of the
>> JaCoCo jars.
>
> As a first step, I've updated Derby-JaCoCo to use the latest version of
> JaCoCo (0.7.9). I did this by updating the following variables in the
> build section of the configuration:
>
> jacoco_version=0.7.9
> jacoco_zip_sha1=1d56a66be0f4a6b529d8f983ab65cc77a52cccb6
> jacocoant_sha1=87aa22de3854fd5a43e37a17c4b245b01a46de93
> jacocoagent_sha1=a6ac9cca89d889222a40dab9dd5039bfd22a4cff
>
> I had to download the JaCoCo zip file locally and extract it to
> calculate the SHA1 checksums of the zip file and the two jar files we
> need from it. The checksums are used by the build script to check if we
> already have the right version, or if we have to download it from Maven.
>
> I've kicked off a build, and it has already passed the point where it
> failed before, so maybe that's all that was needed. Let's see what
> happens...

The build job completed and produced a coverage report, so there is
improvement. 10 tests failed, though, so the job is still marked as
"unstable".

-- 
Knut Anders