Thanks a lot for the comprehensive informations, Aditya!
I somehow missed this activity or simply forgot.
The hooks are not generated by default, during the build, right? If we
would do this automatically we could close this gap (which is minor
because the build does the checks anyway).
For plugins, this is indeed a problem because we do not have a build
mechanism there. We could check through the framework build with
integrated plugins, which is the only way to automatically test the
plugins anyway. The problem would be the counter which is targeted at
the framework code.
Is it possible to specify folder groups or packages to check separately
so that the framework build could check against one counter for the
framework code and another counter for the plugins code?
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.02.21 um 13:00 schrieb Aditya Sharma:
Hi Michael,
With OFBIZ-11304[1], we introduced a Gradle plugin
git-hooks-gradle-plugin[2]. The plugin generates a pre-push hook on the
developer's local. I think as the plugin persists it should work along with
the forks too. Along with that, we used GitHub action that runs
checkstyleMain task on PRs as discussed here[3].
We only introduced these with ofbiz-framework repository and not with
ofbiz-plugins. We do not have Gradle in place for the ofbiz-plugin
repository so the same arrangement cannot be done and as discussed here[4]
it's checked while checking the trunk in Buildbot.
The new checkstyle issues must be introduced from the plugins I guess.
1. https://issues.apache.org/jira/browse/OFBIZ-11304
2. https://github.com/jakemarsden/git-hooks-gradle-plugin
3.
https://issues.apache.org/jira/browse/OFBIZ-11304?focusedCommentId=17138097&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17138097
4.
https://issues.apache.org/jira/browse/OFBIZ-11251?focusedCommentId=17183889&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17183889
Thanks and regards,
Aditya Sharma
On Thu, Feb 4, 2021 at 4:33 PM Michael Brohl <michael.br...@ecomify.de>
wrote:
Hi Girish,
which githook plugin are you using? I found several, not sure which one
to choose.
It seems that they do exactly what I described, just have to check. If
this is the case, I would recommend to use such a Gradle plugin which
automatically sets up the git hooks in the local repository and closes
the gap.
I will create a Jira issue for this.
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.02.21 um 11:42 schrieb Girish Vasmatkar:
Hi Michael/Jacques
+1 for the proposal. However, I do not face this issue on my local,
partly
because I never tried to push to the repository without running any
gradle
command. The gitHook gradle plug-in is essentially creating hooks on the
local repository that's why when I push to my forked OFBiz repo, pre-push
hook always gets executed forcing me to conform to checkstyle standards
on
my forked repo too.
Best Regards,
Girish
On Thu, Feb 4, 2021 at 1:34 PM Jacques Le Roux <
jacques.le.r...@les7arts.com>
wrote:
Le 03/02/2021 à 17:59, Michael Brohl a écrit :
So I think we should find a way to deploy the hooks to the user's local
repository to make sure they are used there also. Else we would always
chase
after newly introduced checkstyle problems, especially if we use pull
requests.
I found a solution here:
https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/
(at the bottom of the page). This must be
adapted for Gradle to be dependend of a build.
This would keep our hooks versioned in the repository and would
automatically install the hooks in the local repository.
What do you think?
Hi Michael,
It looks like a good idea to me. A Jira would fit.
In the meantime you need to fix the checkstyle issues put in with
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1973
details here:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1973/steps/check/logs/stdio
TIA
Jacques
