action #151219


[bug][os-autoinst-distri-opensuse] No .perltidyrc

Added by clanig 5 months ago. Updated 5 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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.


Related issues 1 (0 open1 closed)

Related to openQA Project - action #138416: Unify GitHub Actions for QA Projects size:MResolvedybonatakis2023-10-24

Actions #1

Updated by okurz 5 months ago

  • Category set to Regressions/Crashes
  • Target version set to Ready
Actions #2

Updated by tinita 5 months 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.

Actions #3

Updated by tinita 5 months 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.

Actions #4

Updated by okurz 5 months ago

  • Status changed from New to Resolved
  • Assignee set to tinita
Actions #5

Updated by clanig 5 months 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.

Actions #6

Updated by tinita 5 months 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 :)

Actions #7

Updated by tinita 5 months ago

  • Related to action #138416: Unify GitHub Actions for QA Projects size:M added
Actions #8

Updated by clanig 5 months ago

Thanks! :)


Also available in: Atom PDF