action #151219
closed[bug][os-autoinst-distri-opensuse] No .perltidyrc
Description
Running tidyall
on os-autoinst-distri-opensuse leads to an error message: cannot find file given with -pro=/home/clanig/Documents/gits/os-autoinst-distri-opensuse/.perltidyrc: No such file or directory.
Reason: There is no .perltidyrc
in the root directory of os-autoinst-distri-opensuse
, but an attribute in .tidyallrc
for [perltidy]
: argv = --pro=$ROOT/.perltidyrc
.
Together with the insufficient error message: "File [...] needs tidying", it can be considered impossible to tidy commits properly, since there are no rules specified how a file shall look like when it is tidied.
C.f. https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18095
Updated by okurz about 1 year ago
- Category set to Regressions/Crashes
- Target version set to Ready
Updated by tinita about 1 year ago
Try calling
make prepare
before. It will clone os-autoinst as a subdirectory, and then the symlink .perltidyrc
should point to the file in there.
Updated by tinita about 1 year ago
Also, it's recommended to call ./tools/tidy
, which is a wrapper around tidyall. It does a check on the perltidy version and will complain if you have a different one installed than needed.
Updated by okurz about 1 year ago
- Status changed from New to Resolved
- Assignee set to tinita
Also that is explained on https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/CONTRIBUTING.md#preparing-a-new-pull-request . That should cover it.
Updated by clanig about 1 year ago ยท Edited
Thanks a lot for pointing that out!
I have checked the code of the Makefile target prepare
and understand that it links .perltidyrc
of os-autoinst
into the root directory of os-autoinst-distri-opensuse
.
This has the benefit on the side of maintaining the contribution constraints more easily, centrally and, by that, coherently. It has the disadvantage that the repository is no encapsulated module maintainable on it's own, but requires manual steps by each contributor to provide all constraints required to contribute to it.
I would personally prefer redundancy in favor of distinctive modules to an acceptable extend, also to provide some kind of expected workflow of contribution without too many distinct rules in Markdown files. With other words: If there is a .tidyallrc
, it appears intuitive to expect the ability to run tidyall out of the box without issues. From my perspective the number of times the repo is cloned and requires the make prepare
step might create more work than applying changes to two .tidyrc
files instead of one if changes are made.
If further steps are required to add optional resources, I would personally understand that much better.
Edit: I really have to resolve a lot dependency issues to run make prepare
, and it pulls many CPAN modules which I don't need, just to get a link to the .perltidyrc
.
Updated by tinita about 1 year ago
We are currently working on a hopefully better way to centralize static checks, see #138416
This might make the linking of os-autoinst not necessary anymore. So stay tuned :)
Updated by tinita about 1 year ago
- Related to action #138416: Unify GitHub Actions for QA Projects size:M added