You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@gmail.com> on 2017/11/18 15:25:09 UTC
fiixing JaCoCo, was: need help configuring Jenkins
I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
JaCoCo jars at http://people.apache.org/~rhillegas/derby/jacoco-jars/.
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? See
https://builds.apache.org/view/All/job/Derby-JaCoCo/configure
and
https://builds.apache.org/view/All/job/Derby-trunk-JaCoCo/configure
Thanks,
-Rick
On 11/7/17 4:19 PM, Rick Hillegas wrote:
> On 11/6/17 5:06 PM, Rick Hillegas wrote:
>> On 11/5/17 7:36 PM, Bryan Pendleton wrote:
>>>>> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
>>>>> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>>>> If I understand that script, our JaCoCo runs rely on an old JaCoCo
>>>> version
>>>> cached on Kristian's Apache website. Here are some things we could do:
>>>>
>>>> 1) Ask Kristian to upgrade the JaCoCo version in his cache.
>>>>
>>>> 2) Cache a newer version on my Apache website and tweak the script
>>>> accordingly.
>>> Either one of those seems fine to me.
>>>
>>> If you fetch the newest version of the JaCoCo jars and put them on
>>> your Apache site,
>> I have copied the latest 0.7.9 artifacts to the
>> public_html/derby/jacoco-jars directory of my apache account by
>> sftping to minotaur.apache.org. But the artifacts are not visible at
>> people.apache.org/~rhillegas and the directory tree there differs
>> from the one on minotaur. I'm confused. I thought that all the apache
>> machines shared the same account space. I guess it's time for another
>> lesson from infra. Stay tuned...
> Ok, the new jars are now visible from people.apache.org. The two
> machines no longer share an account space.
>>> I'd be glad to fiddle the Jenkins configuration and see if it fixes
>>> the problem.
>>>
>>> thanks,
>>>
>>> bryan
>>>
>>
>
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@gmail.com> writes:
> On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
>> Knut Anders Hatlen <kn...@oracle.com> writes:
>>
>>> Rick Hillegas <ri...@gmail.com> writes:
>>>
>>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>>> Rick Hillegas <ri...@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".
> Thanks, Knut. The failures all result from a missing FilePermission
> under DropDatabaseSetup while checking for the existence of a
> directory before deleting it. The tests work standalone on my machine.
> Do you remember if the JaCoCo test runs have their own security
> policy, which might need to be updated?
Hi Rick,
I think they use the ordinary policy files, but the extra permissions
needed for JaCoCo are guarded by the jacoco.active system property. For
example:
permission java.io.FilePermission "${jacoco.active}${user.dir}${/}*", "read, write";
When JaCoCo is active, the jacoco.active property is set to the empty
string, so that the above rule becomes equivalent to
permission java.io.FilePermission "${user.dir}${/}*", "read, write";
and thereby becomes active.
The code that sets the jacoco.active property seems to be located in
BaseTestCase and SecurityManagerSetup.
--
Knut Anders
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
> Knut Anders Hatlen <kn...@oracle.com> writes:
>
>> Rick Hillegas <ri...@gmail.com> writes:
>>
>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>> Rick Hillegas <ri...@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".
Thanks, Knut. The failures all result from a missing FilePermission
under DropDatabaseSetup while checking for the existence of a directory
before deleting it. The tests work standalone on my machine. Do you
remember if the JaCoCo test runs have their own security policy, which
might need to be updated?
Thanks,
-Rick
>
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Knut Anders Hatlen <kn...@oracle.com> writes:
> Rick Hillegas <ri...@gmail.com> writes:
>
>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas <ri...@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
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@gmail.com> writes:
> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@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...
--
Knut Anders
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@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.
Cheers,
-Rick
>
>> See
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=wulacnvwG-OWc5lbUU9q382NzVuIur7Z7LVngjcHYPU&e=
>>
>> and
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2Dtrunk-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=YOFIV1NAlpMLVIwmKggAqSvt93XoNP1PMcQU_jPbBgo&e=
>>
>> Thanks,
>> -Rick
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@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.
> See
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=wulacnvwG-OWc5lbUU9q382NzVuIur7Z7LVngjcHYPU&e=
>
> and
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2Dtrunk-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=YOFIV1NAlpMLVIwmKggAqSvt93XoNP1PMcQU_jPbBgo&e=
>
> Thanks,
> -Rick
--
Knut Anders