Adding other modules - what is your policy?
szabgab opened this issue · 9 comments
I just bumped into this image and started to use it.
The first thing I wanted to use it with also asked to install
JSON and Alien::Build
Another project required
Test::Requires, Plack::Test, Test::SharedFork, Test::TCP, Test::Time (and probably a few others)
I'd be glad to send the respective PRs, but I thought I'd ask first what do you think?
What is your policy of inclusion.
Good question. The idea is to provide the modules which might be generally required to build and/or test a CPAN distribution. I think all of those test modules would fall into this category.
As far as JSON and Alien::Build go, my first impression would be that they are outside the scope of this project. I will ask @atoomic to chime in as well, though.
If you want to go ahead and send a PR for adding more test modules, that's great. I would watch the build results on those to make sure they all install cleanly. If something is only installable on a later Perl version, we can manage that in the cpanfile.
There's a nightly build, so anything merged will take a maximum of 24 hours to be available in the next push to Docker hub.
As stated by @oalders the idea is to provide the common list of modules required for testing distro.
This is already bloated enough that this should be a no brainer to add a few extra.
But I would not consider any Alien::* modules being standard and commonly used.
Concerning JSON, I think it's such a common module that we could consider adding it.
We also have to keep in mind that the more modules we add, the more we will hide issues coming from a missing dependency in the distro. (but this is already true).
I would also question how common is Test-TCP and some other test modules... but this is probably fine to have them if it helps you. This is not going to make the images much bigger lol
You can submit one or more PRs to add some extra distro.
The only tricky thing is to know the minimal Perl version required for a distro and add it to the corresponding section in the cpanfile, otherwise build for older Perl will fail.
And to answer to your question, we have no policy outside common sense.
We just want to avoid adding uncommon modules or modules that will bloat the images and slow down every smoke.
I've now realized that we don't actually smoke the changes. We only have a nightly build. So, it would be helpful to smoke on PRs.
Do you run any of the processes yourself or is it all the GitHub Actions?
We should be doing it in actions.
indeed GitHub actions are used to auto release updates, even if you can do it manually this is not happening :-)
I can put a PR together for that.
I think we should close this case and create one for smoking on PRs so we can detect issues when adding new modules for example.