-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centralize perl lint checks #30
base: master
Are you sure you want to change the base?
Conversation
1823dc9
to
4112c8d
Compare
Testing the perltidy config from os-autoinst/os-autoinst-common#30
Testing the perltidy config from os-autoinst/os-autoinst-common#30
Testing the perltidy config from os-autoinst/os-autoinst-common#30
Testing the perltidy config from os-autoinst/os-autoinst-common#30
Testing the perltidy config from os-autoinst/os-autoinst-common#30
1d8fb0e
to
f7f3cc9
Compare
0a8ca65
to
bb7290a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, see the style warnings that you introduced I woul say :)
I tried experimenting on annotations for failed tests, but the test infrastructure lacks a lot on controlling the output. Brute-forcing my way with a GH annotation get's me to a not-so-reliable regex, see it here for the regex and a sample output match: https://regex101.com/r/9HVPpB/1 The furthest I could get was to get which test failed, in: josegomezr/perl-design-patterns: t/lib/TAP/Formatter/GitHubAction.pm). I'll backtrack on that one until a simpler solution rises, for now it'll just be a red check when tests fail. |
9d3d348
to
36b4039
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of things I could comment on.
But I think we should discuss how this should be tested and which existing repositories should use which tools already. Not sure what @okurz had in mind.
I think one necessary step for approval is that this is tested on one of our repos. (For example the tools/update-deps doesn't compile with your changes :)
So I would suggest doing a draft PR with this branch as a subrepo:
git subrepo clone --force [email protected]:josegomezr/os-autoinst-common.git external/os-autoinst-common -b unify_perltidy
runs-on: ubuntu-latest | ||
name: "Perltidy" | ||
container: | ||
image: perldocker/perl-tester:5.26 | ||
steps: | ||
- uses: actions/checkout@v4 | ||
- run: GITHUB_ACTIONS=1 ./tools/tidyall --check-only --all --quiet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think with this we would be getting the latest Perl::Tidy that is installed in that container, so people will have to install that version locally. It will not be in sync with https://build.opensuse.org/package/show/devel:openQA:Leap:15.5/perl-Perl-Tidy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is still requiring some love, I have a pending experiment making this image (perl-tester) in OBS with openqa dependencies instead. I think I spotted something like that already there.
1636ce9
to
6417c43
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the last commit should be squashed into the commit that introduced the code.
Our perl interpret is inherited from SUSE:SLE-15-SP3:Update. So the right question is whether sles can update it. mlschroe should be able to tell us, we're ahead of beta2 so still possible imho. |
@@ -39,8 +40,7 @@ update_spec(); | |||
update_cpanfile($modules_by_target); | |||
update_dockerfile($dockerfile) if $dockerfile; | |||
|
|||
sub update_dockerfile { | |||
my ($dockerfile) = @_; | |||
sub update_dockerfile ($dockerfile) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tried this out in os-autoinst. The script doesn't compile because you still need to enable signatures
99ed5c2
to
0fee352
Compare
Adding a bit more of activity here: In the PoC on my fork of the example distribution (available here I've:
Addenda:
|
@josegomezr it's getting hard to see where we are going overall. I suggest you split out commits from https://github.com/os-autoinst/os-autoinst-common/pull/30/commits into separate PRs that we can get merged and "out of sight" and then rebase here and see what's left. |
- Introducing `tools/tidyall` an improved wrapper over perl's `tidyall`. It does version detection directly in perl and exposes the underlying `tidyall` CLI. - Adds a complementary GitHub Action to run `tools/tidyall` automatically on Pull Requests & Master. - Brings bare minimum dependencies.yaml for running `tools/tidyall`. Adjusted `tools/update-deps` to produce a `cpanfile` alone (without needing an `.spec` file first). - Applied tidy rules. Branched off os-autoinst#30.
- Introducing `tools/perlcritic` an improved wrapper over perl's `perlcritic`. It automatically appends this project's policies that are defined under the `openqa` theme. - Adds a complementary GitHub Action to run `tools/perlcritic` automatically on Pull Requests & Master. - Fixed `perlcritics` complaints. Branched off os-autoinst#30.
#31 & #32 branch off this discussion. Please have a look, they can be merged in isolation. And after that I'll get back this one and finish-off any pending piece. |
- Introducing `tools/perlcritic` an improved wrapper over perl's `perlcritic`. It automatically appends this project's policies that are defined under the `openqa` theme. - Adds a complementary GitHub Action to run `tools/perlcritic` automatically on Pull Requests & Master. - Fixed `perlcritics` complaints. Branched off os-autoinst#30. Co-authored-by: Oliver Kurz <[email protected]> Co-authored-by: Martchus <[email protected]>
- Introducing `tools/perlcritic` an improved wrapper over perl's `perlcritic`. It automatically appends this project's policies that are defined under the `openqa` theme. - Adds a complementary GitHub Action to run `tools/perlcritic` automatically on Pull Requests & Master. - Fixed `perlcritics` complaints. Branched off os-autoinst#30. Co-authored-by: Oliver Kurz <[email protected]> Co-authored-by: Martchus <[email protected]>
@okurz what is needed for this PR to be merged, aside from resolving the coflicts, etc?. I see that there's at least one discussion open, also because looking at the ticket, looks like we're waiting on @os-autoinst/tools-team for all of the related PRs. And since @josegomezr is back to SCC, I would like to know who is going to take over these changes, since it has taken 3 months, and still can't be closed. PS: Before @okurz comes saying again that "I'm asking the team to work faster", the answer is no, but it looks that you prefer to make work more complicated that it should, and being in emergency mode all the time doesn't really help. |
I don't really know what's needed as there had been already quite some changes in the related PRs, e.g. #31, so I suggest to rebase first.
It might fit probably somewhere with https://progress.opensuse.org/issues/108527 but it's better to make that explicit by taking over https://progress.opensuse.org/issues/138416 into the backlog of qe-tools, agreed? |
Sounds like a plan! We can have a chat about the things that are related kind of soonish, and at some other point dig a bit more into https://progress.opensuse.org/issues/108527 |
You'all can ask me too, I moved team not organizations... #32 is missing. after it's merged what's pending is:
That should serve a good baseline to continue downstreaming the tools in #31 & #32 to psa: I'm very bad with technology... |
This pull request is now in conflicts. Could you fix it? 🙏 |
656b9b4
to
29af88e
Compare
- Introducing `tools/perlcritic` an improved wrapper over perl's `perlcritic`. It automatically appends this project's policies that are defined under the `openqa` theme. - Adds a complementary GitHub Action to run `tools/perlcritic` automatically on Pull Requests & Master. - Fixed `perlcritics` complaints. Branched off os-autoinst#30. Co-authored-by: Oliver Kurz <[email protected]> Co-authored-by: Martchus <[email protected]>
- Introducing `tools/perlcritic` an improved wrapper over perl's `perlcritic`. It automatically appends this project's policies that are defined under the `openqa` theme. - Adds a complementary GitHub Action to run `tools/perlcritic` automatically on Pull Requests & Master. - Fixed `perlcritics` complaints. Branched off os-autoinst#30. Co-authored-by: Oliver Kurz <[email protected]> Co-authored-by: Martchus <[email protected]>
With merged can you now rebase here to fix the conflicts? |
Introduced simplified version of
tools/perlcritic
.The perlcritic wrapper provided under
tools/perlcritic
will resolve itselfand append the common perl critic policies defined in this repo automatically
providing a seamless experience.
Introduced simplified version
tools/tidyall
[warning, is breaking].This is a full rework of the script to perform the same tidy version detection
in perl instead of deep
bash + sed
.It'll validate the tidy version and run
tidyall
afterwards.Support for the
--force
flag is also provided transparently.The breaking change comes from the fact that the bash script provided a façade
over tidyall transforming arguments. This is deleted in favor of the real
tidyall arguments.
Downstream repositories will inherit this tools through the subrepo pull workflow.
poo#138416