Milestones for default & optional environment & volume-mapping fields

[kanecko]

I thought of making a parent issue so we can track the progress being made.

• Add support for default values in required environment fields. add env default option for rockons #2012
• Add support for default values in required volume-mapping fields.
• Add support for optional values in environment fields. Rockons: Ability to set environment objects as optional #2094
• Add support for optional values in volume-mapping fields. Optional configuration for rockons #2280
• Update the following Rockons with default and optional fields:
  • pi-hole
  • jellyfin
  • netalertx
  • omada-controller
  • nginx-proxy-manager
  • radarr
  • sonarr
  • transmission
  • (please suggest others as well!)
• Add new Rockon "Unpackerr" Unpackerr rockon-registry#343

[phillxnet]

@FroggyFlox & @Hooverdan96 Should we make this into a Milestone proper? I.e. we have now it seems reached some-what of a critical mass on our Rock-ons v1 lets say: arbitrarily. Maybe we have sufficient interest, re @kanecko renewed presence, to establish a Rock-ons V2 milestone. To be addressed as interest/resources allow, in parallel with our front end updates. Partial conflict but that is unavoidable with the large changes we have already made in the past: and are still planning for re UI dependencies re-vamp.

Super important in all these Rock-ons changes is to not break at least our last Stable, currently 4.6.1-0, and ideally last but one 4.1.0-0. But with our next Stable just around the corner we might only really have to concern ourselves re backward compatibility to 4.6.1-0 in the very near future; as we will then have a 5.1.0-0. And thus far changes such as convenience defaults honours this (at least I think/hope it does).

We need not list all affected Rock-ons as that is redundant and dynamic: we need only collect issues that detail planned Rock-on subsystem improvements. Especially as we have to honour all existing installs (last one or two stables). Alternatively we just use issue labels: but they are less obvious progress wise. And if we have a renewed interest in upping the Rock-on sub-system it would be good to establish this up-front via an Issue Milestone.

@kanecko Great to have renewed interest in our Rock-ons subsystem. However we are unlikely to be able to cram any of these deeper (model change) improvements into the next Stable (current testing before Stable spin-off) but that does give us way more leeway to make bolder changes in the testing channel there-after (soon). So all good: especially as we are all after a much shorter testing phase the next go around.