Re: Code coverage check for PRs

[Robert Muir]

We already have code coverage integrated into the build. See the
documentation on how to generate the reports:
https://github.com/apache/lucene/blob/main/help/tests.txt

I think we should stick with jacoco and not some commercial stuff for
measuring coverage. Jacoco works great. We just have to put the
reports or stats somewhere useful.

On Tue, Oct 4, 2022 at 5:45 PM Patrick Zhai  wrote:
>
> Hi Robert, thank you for commenting, yeah the functionality I want to add is 
> actually the line by line code coverage stats for the new/changed line that 
> are in the patch so that we don't need to wonder about "whether that line is 
> covered by the test?". But I'm against using the code coverage as any kind of 
> hard criteria, like coverage must be kept at a certain % or all the new lines 
> must be covered, that will drive people crazy. I think that should be just 
> treated as a helpful thing to check when reviewing/creating the PR.
>
> I searched a little on google and found this: https://about.codecov.io/, it's 
> free for open source and seems to have the functionality we need. Let me know 
> if anyone has ideas about this, or otherwise I can try it a little bit with 
> my own repo first and then try to add it to lucene.
>
> Best
> Patrick
>
>
>
> On Tue, Oct 4, 2022, 06:36 Robert Muir  wrote:
>>
>> btw, you can look at the current reports created by jenkins here:
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Coverage-main/lastBuild/jacoco/
>>
>> On Tue, Oct 4, 2022 at 6:51 AM Robert Muir  wrote:
>> >
>> > we can run the tests with coverage option and produce coverage graph
>> > from the github actions, but need to look at the docs to see where to
>> > put it so it will be available.
>> >
>> > I want us to be careful about the word "check" as I'm adamantly
>> > against any such automated check (e.g. coverage > N%) in the logic.
>> > Coverage report is just a tool to help us and the moment we do stupid
>> > shit like that, is the moment people start gaming it just to make the
>> > build pass.
>> >
>> > On Mon, Oct 3, 2022 at 10:57 PM Patrick Zhai  wrote:
>> > >
>> > > Hi folks,
>> > > I'm not sure whether people have already discussed this but I'm 
>> > > wondering whether we want to add a workflow that pulls out the code 
>> > > coverage whenever a PR was created? It should be easier for both the 
>> > > reviewers and the contributors to figure out what can be improved, or at 
>> > > least figure out a part that is probably not covered by the tests?
>> > >
>> > > Best
>> > > Patrick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Code coverage check for PRs

[Patrick Zhai]

Hi Robert, thank you for commenting, yeah the functionality I want to add
is actually the line by line code coverage stats for the new/changed line
that are in the patch so that we don't need to wonder about "whether that
line is covered by the test?". But I'm against using the code coverage as
any kind of hard criteria, like coverage must be kept at a certain % or all
the new lines must be covered, that will drive people crazy. I think that
should be just treated as a helpful thing to check when
reviewing/creating the PR.

I searched a little on google and found this: https://about.codecov.io/,
it's free for open source and seems to have the functionality we need.
Let me know if anyone has ideas about this, or otherwise I can try it a
little bit with my own repo first and then try to add it to lucene.

Best
Patrick



On Tue, Oct 4, 2022, 06:36 Robert Muir  wrote:

> btw, you can look at the current reports created by jenkins here:
>
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Coverage-main/lastBuild/jacoco/
>
> On Tue, Oct 4, 2022 at 6:51 AM Robert Muir  wrote:
> >
> > we can run the tests with coverage option and produce coverage graph
> > from the github actions, but need to look at the docs to see where to
> > put it so it will be available.
> >
> > I want us to be careful about the word "check" as I'm adamantly
> > against any such automated check (e.g. coverage > N%) in the logic.
> > Coverage report is just a tool to help us and the moment we do stupid
> > shit like that, is the moment people start gaming it just to make the
> > build pass.
> >
> > On Mon, Oct 3, 2022 at 10:57 PM Patrick Zhai  wrote:
> > >
> > > Hi folks,
> > > I'm not sure whether people have already discussed this but I'm
> wondering whether we want to add a workflow that pulls out the code
> coverage whenever a PR was created? It should be easier for both the
> reviewers and the contributors to figure out what can be improved, or at
> least figure out a part that is probably not covered by the tests?
> > >
> > > Best
> > > Patrick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Code coverage check for PRs

[Robert Muir]

btw, you can look at the current reports created by jenkins here:
https://ci-builds.apache.org/job/Lucene/job/Lucene-Coverage-main/lastBuild/jacoco/

On Tue, Oct 4, 2022 at 6:51 AM Robert Muir  wrote:
>
> we can run the tests with coverage option and produce coverage graph
> from the github actions, but need to look at the docs to see where to
> put it so it will be available.
>
> I want us to be careful about the word "check" as I'm adamantly
> against any such automated check (e.g. coverage > N%) in the logic.
> Coverage report is just a tool to help us and the moment we do stupid
> shit like that, is the moment people start gaming it just to make the
> build pass.
>
> On Mon, Oct 3, 2022 at 10:57 PM Patrick Zhai  wrote:
> >
> > Hi folks,
> > I'm not sure whether people have already discussed this but I'm wondering 
> > whether we want to add a workflow that pulls out the code coverage whenever 
> > a PR was created? It should be easier for both the reviewers and the 
> > contributors to figure out what can be improved, or at least figure out a 
> > part that is probably not covered by the tests?
> >
> > Best
> > Patrick

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Code coverage check for PRs

[Robert Muir]

we can run the tests with coverage option and produce coverage graph
from the github actions, but need to look at the docs to see where to
put it so it will be available.

I want us to be careful about the word "check" as I'm adamantly
against any such automated check (e.g. coverage > N%) in the logic.
Coverage report is just a tool to help us and the moment we do stupid
shit like that, is the moment people start gaming it just to make the
build pass.

On Mon, Oct 3, 2022 at 10:57 PM Patrick Zhai  wrote:
>
> Hi folks,
> I'm not sure whether people have already discussed this but I'm wondering 
> whether we want to add a workflow that pulls out the code coverage whenever a 
> PR was created? It should be easier for both the reviewers and the 
> contributors to figure out what can be improved, or at least figure out a 
> part that is probably not covered by the tests?
>
> Best
> Patrick

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Missing tags for releases 8.8.2 thru 8.11.2

[Dawid Weiss]

It was cloned to preserve history (git blame, etc.) but it was decided to
keep 8x development in the shared repo so that the continuity is kept there
(for that major version) rather than in Solr or Lucene after the split.

Dawid

On Tue, Oct 4, 2022 at 11:32 AM Shad Storhaug  wrote:

> Thanks Dawid. I just needed to know where to locate them, so this is fine.
> I guess I thought the repository moved rather than being cloned, but this
> makes total sense after you explained it.
>
>
>
> *From:* Adrien Grand 
> *Sent:* Tuesday, October 4, 2022 2:25 PM
> *To:* Dawid Weiss 
> *Cc:* dev@lucene.apache.org
> *Subject:* Re: Missing tags for releases 8.8.2 thru 8.11.2
>
>
>
> Ahhh thanks Dawid, this makes sense.
>
>
>
> On Tue, Oct 4, 2022 at 9:23 AM Dawid Weiss  wrote:
>
>
>
> Tags seem to exist on the lucene-solr repository (
> https://github.com/apache/lucene-solr) so maybe they were missed from the
> migration when we did the Lucene/Solr split? +Dawid Weiss
>  I wonder if you have thoughts on this.
>
>
>
> I don't think anything has been missed. Solr and Lucene had a common git
> repository up until version 8.8.1 and this tag is reflected in Lucene's
> now-current git:
>
>
>
> https://github.com/apache/lucene/tree/releases/lucene-solr/8.8.1
>
>
>
> All subsequent releases for the 8.x line have been made from the common
> repository _after the split_ - these tags only exist back in the common
> repository, they're not forward-ported to the Lucene-only repository. Those
> historical tags are there for, well, historical reasons. If you're looking
> for the exact code commit for 8.11.0, you have to look back at the
> lucene-solr repository (which is the maintenance for the 8.x line), here:
>
>
>
> https://github.com/apache/lucene-solr/tree/releases/lucene-solr/8.11.0
>
>
>
> Anticipating the question, I don't think it makes sense to forward-port
> commits from lucene-solr to lucene - this would only create additional
> confusion as to where the development/ maintenance actually takes place.
>
>
>
> Dawid
>
>
>
>
>
> On Tue, Oct 4, 2022 at 7:55 AM Shad Storhaug 
> wrote:
>
> I was just conversing with a user who mentioned he was using Lucene
> 8.11.0, but when I checked the repo there is no release with that version,
> it ends at 8.8.1. Then I checked on mvnrepository.com and they do exist:
> https://mvnrepository.com/artifact/org.apache.lucene/lucene-core.
>
>
>
> So what gives? Why were these releases not tagged in the repo? If they are
> tagged using a different format, please let me know what the other format
> is.
>
>
>
> Thanks,
>
> Shad Storhaug (NightOwl888)
>
> Project Chairperson – Apache Lucene.NET
>
>
>
>
> --
>
> Adrien
>
>
>
>
> --
>
> Adrien
>

RE: Missing tags for releases 8.8.2 thru 8.11.2

[Shad Storhaug]

Thanks Dawid. I just needed to know where to locate them, so this is fine. I 
guess I thought the repository moved rather than being cloned, but this makes 
total sense after you explained it.

From: Adrien Grand 
Sent: Tuesday, October 4, 2022 2:25 PM
To: Dawid Weiss 
Cc: dev@lucene.apache.org
Subject: Re: Missing tags for releases 8.8.2 thru 8.11.2

Ahhh thanks Dawid, this makes sense.

On Tue, Oct 4, 2022 at 9:23 AM Dawid Weiss 
mailto:dawid.we...@gmail.com>> wrote:

Tags seem to exist on the lucene-solr repository 
(https://github.com/apache/lucene-solr) so maybe they were missed from the 
migration when we did the Lucene/Solr split? +Dawid 
Weiss I wonder if you have thoughts on this.

I don't think anything has been missed. Solr and Lucene had a common git 
repository up until version 8.8.1 and this tag is reflected in Lucene's 
now-current git:

https://github.com/apache/lucene/tree/releases/lucene-solr/8.8.1

All subsequent releases for the 8.x line have been made from the common 
repository _after the split_ - these tags only exist back in the common 
repository, they're not forward-ported to the Lucene-only repository. Those 
historical tags are there for, well, historical reasons. If you're looking for 
the exact code commit for 8.11.0, you have to look back at the lucene-solr 
repository (which is the maintenance for the 8.x line), here:

https://github.com/apache/lucene-solr/tree/releases/lucene-solr/8.11.0

Anticipating the question, I don't think it makes sense to forward-port commits 
from lucene-solr to lucene - this would only create additional confusion as to 
where the development/ maintenance actually takes place.

Dawid


On Tue, Oct 4, 2022 at 7:55 AM Shad Storhaug 
mailto:s...@shadstorhaug.com>> wrote:
I was just conversing with a user who mentioned he was using Lucene 8.11.0, but 
when I checked the repo there is no release with that version, it ends at 
8.8.1. Then I checked on mvnrepository.com and they 
do exist: https://mvnrepository.com/artifact/org.apache.lucene/lucene-core.

So what gives? Why were these releases not tagged in the repo? If they are 
tagged using a different format, please let me know what the other format is.

Thanks,
Shad Storhaug (NightOwl888)
Project Chairperson – Apache Lucene.NET


--
Adrien


--
Adrien

Re: Missing tags for releases 8.8.2 thru 8.11.2

[Adrien Grand]

Ahhh thanks Dawid, this makes sense.

On Tue, Oct 4, 2022 at 9:23 AM Dawid Weiss  wrote:

>
> Tags seem to exist on the lucene-solr repository (
>> https://github.com/apache/lucene-solr) so maybe they were missed from
>> the migration when we did the Lucene/Solr split? +Dawid Weiss
>>  I wonder if you have thoughts on this.
>>
>
> I don't think anything has been missed. Solr and Lucene had a common git
> repository up until version 8.8.1 and this tag is reflected in Lucene's
> now-current git:
>
> https://github.com/apache/lucene/tree/releases/lucene-solr/8.8.1
>
> All subsequent releases for the 8.x line have been made from the common
> repository _after the split_ - these tags only exist back in the common
> repository, they're not forward-ported to the Lucene-only repository. Those
> historical tags are there for, well, historical reasons. If you're looking
> for the exact code commit for 8.11.0, you have to look back at the
> lucene-solr repository (which is the maintenance for the 8.x line), here:
>
> https://github.com/apache/lucene-solr/tree/releases/lucene-solr/8.11.0
>
> Anticipating the question, I don't think it makes sense to forward-port
> commits from lucene-solr to lucene - this would only create additional
> confusion as to where the development/ maintenance actually takes place.
>
> Dawid
>
>
>> On Tue, Oct 4, 2022 at 7:55 AM Shad Storhaug 
>> wrote:
>>
>>> I was just conversing with a user who mentioned he was using Lucene
>>> 8.11.0, but when I checked the repo there is no release with that version,
>>> it ends at 8.8.1. Then I checked on mvnrepository.com and they do
>>> exist: https://mvnrepository.com/artifact/org.apache.lucene/lucene-core.
>>>
>>>
>>>
>>> So what gives? Why were these releases not tagged in the repo? If they
>>> are tagged using a different format, please let me know what the other
>>> format is.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Shad Storhaug (NightOwl888)
>>>
>>> Project Chairperson – Apache Lucene.NET
>>>
>>
>>
>> --
>> Adrien
>>
>

-- 
Adrien

Re: Missing tags for releases 8.8.2 thru 8.11.2

[Dawid Weiss]

> Tags seem to exist on the lucene-solr repository (
> https://github.com/apache/lucene-solr) so maybe they were missed from the
> migration when we did the Lucene/Solr split? +Dawid Weiss
>  I wonder if you have thoughts on this.
>

I don't think anything has been missed. Solr and Lucene had a common git
repository up until version 8.8.1 and this tag is reflected in Lucene's
now-current git:

https://github.com/apache/lucene/tree/releases/lucene-solr/8.8.1

All subsequent releases for the 8.x line have been made from the common
repository _after the split_ - these tags only exist back in the common
repository, they're not forward-ported to the Lucene-only repository. Those
historical tags are there for, well, historical reasons. If you're looking
for the exact code commit for 8.11.0, you have to look back at the
lucene-solr repository (which is the maintenance for the 8.x line), here:

https://github.com/apache/lucene-solr/tree/releases/lucene-solr/8.11.0

Anticipating the question, I don't think it makes sense to forward-port
commits from lucene-solr to lucene - this would only create additional
confusion as to where the development/ maintenance actually takes place.

Dawid


> On Tue, Oct 4, 2022 at 7:55 AM Shad Storhaug 
> wrote:
>
>> I was just conversing with a user who mentioned he was using Lucene
>> 8.11.0, but when I checked the repo there is no release with that version,
>> it ends at 8.8.1. Then I checked on mvnrepository.com and they do exist:
>> https://mvnrepository.com/artifact/org.apache.lucene/lucene-core.
>>
>>
>>
>> So what gives? Why were these releases not tagged in the repo? If they
>> are tagged using a different format, please let me know what the other
>> format is.
>>
>>
>>
>> Thanks,
>>
>> Shad Storhaug (NightOwl888)
>>
>> Project Chairperson – Apache Lucene.NET
>>
>
>
> --
> Adrien
>

Re: Missing tags for releases 8.8.2 thru 8.11.2

[Adrien Grand]

Tags seem to exist on the lucene-solr repository (
https://github.com/apache/lucene-solr) so maybe they were missed from the
migration when we did the Lucene/Solr split? +Dawid Weiss
 I wonder if you have thoughts on this.

On Tue, Oct 4, 2022 at 7:55 AM Shad Storhaug  wrote:

> I was just conversing with a user who mentioned he was using Lucene
> 8.11.0, but when I checked the repo there is no release with that version,
> it ends at 8.8.1. Then I checked on mvnrepository.com and they do exist:
> https://mvnrepository.com/artifact/org.apache.lucene/lucene-core.
>
>
>
> So what gives? Why were these releases not tagged in the repo? If they are
> tagged using a different format, please let me know what the other format
> is.
>
>
>
> Thanks,
>
> Shad Storhaug (NightOwl888)
>
> Project Chairperson – Apache Lucene.NET
>


-- 
Adrien