Hi Michael,
I forgot this email and only reapply the initial one. I have just completed the
task. The PR can be closed.
TIA
Jacques
Le 04/02/2024 à 11:54, Michael Brohl a écrit :
See https://issues.apache.org/jira/browse/OFBIZ-12888 and
https://github.com/apache/ofbiz-framework/pull/687
Regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.02.24 um 11:43 schrieb Michael Brohl:
Hi,
I'm currently working on a solution for this.
Maybe someone can explain why we use the GroovyScripts source set for the
codenarc checks in the pre-push hook:
gitHooks {
hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
}
That target seems to be automatically defined through the source set definition
for groovyScripts.
If I remove that source set and the following task configuration:
tasks.named('compileGroovyScriptsGroovy') {
// We don't want to build groovyScripts as they should be considered as
standalone elements executed in
// isolation by ofbiz. Building them will result in numerous error due to
duplicated classes.
enabled = false
}
And change the git hooks to
}
gitHooks {
hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
}
(which is accoring to the pre-push hook definition in .git/hooks/pre-push)
everything seems to work fine, tests are working and the codenarc Main and Test
reports are build.
I provide a PR for it.
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.02.24 um 08:25 schrieb Jacques Le Roux:
Hi Michael,
OK thanks, I'll have a look when I'll get a chance.
It's also weird that it works locally on both Ubuntu 20.04 and Win7 and that BB
fails. Anyway, so far BB is our guardian.
Jacques
Le 03/02/2024 à 23:36, Michael Brohl a écrit :
Hi Jacques,
the commit fixes an issue with the classpath generation of the "eclipse" gradle task
which produces double entries for the "src/main/groovy" path.
The initial issue is caused by the "src/main/groovy" path set twice in build gradle, for the "main" and for the "groovyScripts" source sets. The
second source set entry was removed and the build works as expected.
Instead of reverting the commit, the buildbot process should be checked and repaired. I guess that there is a configuration somewhere which
relies on the path being present at a stage where it is not after the change. It looks like it has something to do with the codenarc tasks.
I am not familiar enough with the codenarc task to help with that, any help
from others to have both issues fixed is appreciated.
Thanks and regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 03.02.24 um 11:01 schrieb Jacques Le Roux:
Sorry, to allow BB to build, I had to revert this commit:
https://github.com/apache/ofbiz-framework/commit/a2f3ec88309f8440fe65b227ff3fc2df279dde24
Please refer to INFRA-25456 for more information. I still don't understand why
it works locally though, any idea?
Jacques
Le 02/02/2024 à 17:57, Jacques Le Roux a écrit :
Hi,
I have created https://issues.apache.org/jira/browse/INFRA-25456 for that
Jacques
Le 02/02/2024 à 14:14, [email protected] a écrit :
Build status: BUILD FAILED: failed Codenarc copied. (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/635
Blamelist: Michael Brohl <[email protected]>, Michael Brohl
<[email protected]>
Build Text: failed Codenarc copied. (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] 625b80dbc626db35dddbaa62057e34b20ae7c38c
Steps:
worker_preparation: 0
git: 0
pullAllPluginsSource: 0
build: 0
check: 0
Copy checkstyle to destination directory structure: 0
Copy codenarc to destination directory structure: 2
clean things: 0
-- ASF Buildbot
