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

Steve Rowe commented on LUCENE-8106:
------------------------------------

bq.  git.exe is undefined everywhere - except the master Jenkins (Linux), which 
has GIT, but no other slave machine has GIT installed. They only use Jenkins' 
internal JGit client, no command line. There is no need to have Git for running 
Lucene builds (except packaging and jar version numbers, but Policeman does not 
use this - because it's optional for test builds).

{{reproduceJenkinsFailures.py}} modifies the checked out revision in three 
different ways:

# Checks out the revision at which the original failure(s) occurred (phase: 
initial setup)
# Checks out the tip of the branch on which the original failure occurred 
(phase: If any test reproduces 100%)
# Checks out the original workspace revision (phase: cleanup)

What do you think ought to be done on OS VMs without git?

> Add script to attempt to reproduce failing tests from a Jenkins log
> -------------------------------------------------------------------
>
>                 Key: LUCENE-8106
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8106
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Steve Rowe
>            Assignee: Steve Rowe
>            Priority: Major
>             Fix For: master (8.0), 7.3
>
>         Attachments: LUCENE-8106-part2.patch, LUCENE-8106.patch, 
> LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>      python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Reply via email to