QA (public)

I just did a little fix to the code reading Makefile.PL to also fetch the TEST_REQUIRES.

We should still add META.json, and additionally check the dynamic_config property - if false, we don't need to read Makefile.PL, Build.PL etc.

I think the generic "QA" project is better fitting. Or is it really connected to "openQA"?

merged https://github.com/openSUSE/cpanspec/pull/28

ok, what's left to call this ticket "Resolved" after the merged PR?

What's left? Reading META.json and also decide further actions depending on dynamic_config.

I ran the current cpanspec on about 20% of the modules (from perl-ACH to perl-Data-Munge) in devel:languages:perl, looked if the changes are expected and committed them to a local git repository.

Now I can make changes to cpanspec and run it on all of those modules to ensure there are no unexpected changes.

I'm also creating a Dockerfile, so in the future it will be easier to install the cronjob on a new server and get all the dependencies and environment variables right.

I made progress with the dependency handling.

Now the script is reading META.json first.
If META.json is missing or didn't contain any prereqs, META.yml is read and checked for prereqs.

If prereqs have been identified and dynamic_config is false, the step to execute Makefile.PL is skipped.

Also refactored a bit and moved things into subroutines.

Still running the last tests but it looks good.

The next step would be to check the license field, and maybe improve the abstract handling (abstract is a required field in META.json, so we can skip reading it from POD in this case).

I ran some more tests and fixed some minor bugs, and also stumbled over a bug related to @INC.
Data::Rand::Obscure has this Build.PL:
https://metacpan.org/source/RKRIMEN/Data-Rand-Obscure-0.021/Build.PL

Because the . has been removed from @INC, what happened with the current cpanspec version is that cpanspec's root path was added to @INC, so it loaded cpanspec's own Makefile.PL instead of the module's one, which lead to the following Require entries https://build.opensuse.org/package/view_file/devel:languages:perl/perl-Data-Rand-Obscure/perl-Data-Rand-Obscure.spec?expand=1:

BuildRequires:  perl-macros
BuildRequires:  perl(Archive::Tar)
BuildRequires:  perl(Archive::Zip)
BuildRequires:  perl(Carp::Clan)
BuildRequires:  perl(IO::Uncompress::Bunzip2)
BuildRequires:  perl(LWP::UserAgent)
BuildRequires:  perl(Module::Build)
BuildRequires:  perl(Object::Tiny)
BuildRequires:  perl(Parse::CPAN::Packages)
BuildRequires:  perl(Pod::Simple::TextContent)
BuildRequires:  perl(Text::Autoformat)
BuildRequires:  perl(YAML)
Requires:       perl(Archive::Tar)
Requires:       perl(Archive::Zip)
Requires:       perl(Carp::Clan)
Requires:       perl(IO::Uncompress::Bunzip2)
Requires:       perl(LWP::UserAgent)
Requires:       perl(Object::Tiny)
Requires:       perl(Parse::CPAN::Packages)
Requires:       perl(Pod::Simple::TextContent)
Requires:       perl(Text::Autoformat)
Requires:       perl(YAML)

My new version moved the code around and didn't put the cpanspec root path to @INC anymore, so I stumbled upon this.

I cleaned up the new code a bit, added a debug mode.
Also I added parseable statistics output (YAML :). With this we can parse the logs of the automatic CPAN-* and d:l:p updates.
This will give us easy access to the meta data of the newest releases.

The new code is also a bit faster (if running Makefile.PL/etc. and/or PPI parsing can be skipped, which is more likely the case for newer modules/releases).
A quick benchmark for 50 modules in d:l:p: 12m5.787s (old) vs. 9m20.203s (new).

I will create an extra ticket for the license improvements, and the statistic data that has been collected until then can be used.

I will run this branch on the autoupdate host for a few days and monitor, and if it looks fine, make a PR.

I rolled out the code on the autoupdate host and will monitor for the next few days.
I installed logrotate for the logfiles (which is something that I wanted to do a long time ago), so logs from the previous day aren't overwritten anymore.