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

Tomoko Uchida commented on LUCENE-9997:
---------------------------------------

I'm late for the party... I recently came up with a similar idea and found this 
issue. Just skimmed through smokeTestRelease.py, I also found some artifacts' 
verifications (e.g. validating the MANIFESTs) can/should be done not only at 
pre-releace check but also at daily development (unless it takes too much time) 
so that problems will be caught in the more early phase.

What I have in mind is, instead of fully replacing the python script (we'll 
need a tool for the release artifact anyway) with Groovy/Java, we could pick 
tasks that can be implemented as independent Gradle tasks and call it from both 
of the smeketester and gradle check (or precommit) task, one by one.

Also, it could be a convenient tool for "manual" artifact checks (for example, 
it could extract and dump all MANIFESTs into a task log file)?

 

If that makes sense, I think I can help with that (after release 9.0).

> Revisit smoketester for 9.0 build
> ---------------------------------
>
>                 Key: LUCENE-9997
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9997
>             Project: Lucene - Core
>          Issue Type: Sub-task
>            Reporter: Robert Muir
>            Priority: Major
>         Attachments: image-2021-10-12-12-47-11-480.png, 
> image-2021-10-12-12-48-15-373.png
>
>          Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> Currently we have a (great) {{dev-tools/scripts/smokeTester.py}} that will 
> perform automated tests against a release.
> This was developed with the ant build process in mind.
> This issue is just about considering the automated checks we do here, maybe 
> some of them can be done efficiently in the gradle build in earlier places: 
> this would be a large improvement!
> Obviously some of them (e.g. GPG release key verifications) are really 
> specific to the artifacts in question. These are most important to release 
> verification, as that is actually the only place we can check it.
> Any other checks (and I do tend to think, this checker should try to be 
> thorough, invoking gradle etc), should be stuff we regularly test in 
> PRs/nightly/builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to