Thank you Allen for the info! I made some progress with the integration for Solr and had several test-runs on SOLR-10912 and SOLR-10783.
I have a WIP script [1] that can executed on a single issue id so it could be used for Precommit jenkins jobs. It... - runs test4tests, notification if no tests were added or updated (comes with Yetus) - runs "@author" tag check (comes with Yetus) - runs the subtasks of "validate" ant action (check lucene version, rat, license check, forbidden apis) for solr and lucene folder, depending on the changed files - runs tests in the modules that were affected. It is still an open discussion what should be tested. 1. I am looking forward to getting feedback, input, ideas! 2. If this is something that we want to pursuit, is there someone who could help me with Jenkins and Jira setup? Thanks, Mano [1] https://github.com/apache/lucene-solr/compare/master...manokovacs:feature/SOLR-10912 On Tue, Jun 20, 2017 at 8:25 AM, Allen Wittenauer <[email protected]> wrote: > On 2017-05-17 19:10 (-0700), David Smiley <[email protected]> > wrote: > > > How else other than a comment could the system communicate results > back to > > > the user? Or do you mean that whatever runs should post a comment, but > > > suppress email notification somehow. > > > > > > > Yes; that. The rationale being that if someone posts a patch, it'll > become > > inevitable that there will be a follow-up bot comment. It's not a big > deal > > though. > > Hi. I hope you don't mind if I chime in here. :) > > When the original JIRA support for Apache Yetus was written, we > actually looked at a way to prevent comments from getting emailed out. At > that point in time, the REST interface lacked the functionality. Much > sadness. But good news: JIRA 7.2.0 does include the necessary magic: > https://jira.atlassian.com/browse/JRASERVER-34423 . Now we just have to > wait until the ASF instance gets upgraded. > > > > If the state is set automatically, how do we know when to set it? > > > > > > Maybe this could be an extra (optional?) step for the committer > looking at > > > the issue? Change to "Patch Available" triggers a run on the most > recent > > > attached patch? > > > > > > > +1 nice idea; seems straight-forward compared to other ideas. I don't > > think we need to limit this transition to only committers though; even > the > > submitter might do it to demonstrate their patch is ready. > > Just to fill in some blanks as to how the current projects are > using it.... > > Submitter sets JIRA issue to Patch Available. There is a job on > ASF Jenkins called "Precommit-Admin" that uses a JIRA filter to look for > (group of projects)+"Patch Available"+(updated time frame). It then > submits any found issues to Precommit-(project)-build with the issue id. > For Solr, Lucene, or any other project, it's just a matter of adding your > project to the JIRA filter and creating the precommit job. Manually > running a job is simple, because you just use that project's dedicated > precommit job and a supplied id. > > [I'm in the process of "rescuing" the precommit-admin codebase > from within the (old) Hadoop svn tree into the much more public Yetus > source tree, writing documentation, etc. Right now, this is all tribal > knowledge. :( ] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
