Re: [wildfly-dev] Tyr - pull request format checker

As an open source project may be better to document somewhere visible to the community. From the initial rules I would suggest drop the "NO JIRA REQUIRED" from commit messages and PR titles, the commit messages and potentially the titles end up in the history of the project and have no meaning outside of the tool. At the moment it looks like the template only covers WildFly so may need a second template to cover WildFly Core. I think from the perspective of the tool making it mandatory for each commit in the PR to contain a Jira ID either with or without the brackets is fine - unless you want to guarantee whitespace around the Jira ID maybe the regular expression could be simplified to ignore the brackets. Also I think it is reasonable for the tool to expect a link in each PR which should also relate to the project the PR is against. Regards, Darran Lofthouse. On Wed, Apr 10, 2019 at 11:35 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > For the demo I've started with this > <https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30>;. For > additional checks I have only something to verify that issue in title > matches the link in the description. Any ideas are welcome! > > I was also thinking about making distinction between issues / bugs and > features if that would be useful. > > I've created a google document to track this - > https://docs.google.com/document/d/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBN... > . > > Martin > > > On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> Do we have somewhere yet that we can start to look into an initial set >> of rules to discuss what the initial set should be? >> >> On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank(a)redhat.com&gt; >> wrote: >> >>> > The time the cross becomes a problem is if we adopt a set of >>> verification rules that we know will regularly trigger a failure to be >>> ignored, if the failure cases to be ignored are truly exceptional cases >>> then the cross will be useful. >>> >>> It would be beneficial to adjust rules as we'll see how useful they are >>> as time progresses. Configuration of rules is external to the service so it >>> will be possible. >>> >>> Martin >>> >>> >>> On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> > OTOH if the mergers decide they want to do something I don't want a >>>>> tool preventing us doing it, which is what my questions were driving at. >>>>> We're way smarter than the tool. >>>>> >>>>> The status should not prevent a possibility of merge but if the cross >>>>> next to the commit would be a problem we can add an override to disable tyr >>>>> check (meaning make it pass manually) with a comment or similar as >>>>> suggested above. >>>>> >>>> >>>> The time the cross becomes a problem is if we adopt a set of >>>> verification rules that we know will regularly trigger a failure to be >>>> ignored, if the failure cases to be ignored are truly exceptional cases >>>> then the cross will be useful. >>>> >>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>>>