Align in-module folder structure to AVM

[AlexanderSehr]

Required changes (AVM ref)

• Question: Should we add a res & ptn folder in the modules folder?
  • Background: Otherwise we only have 'constructs' to rely on which are (to this day) not supported by pipelines & tools
• Update test folder structure #4182
  • Rename folder into e2e
  • Move folder into a new tests folder
  • Update Initialize-Pipeline to support new test folder name
  • Update Pester tests to support new test folder name
  • Update reference to main.bicep in main.test.bicep
  • Update reference to .shared/.scripts
  • Update reference to .shared/.templates
• Update inner test folder names #4183
  • Rename min test folder to defaults
  • Rename common test folder to max
  • Create duplication of common/max folder and name it waf-aligned (don't forget do update the serviceShort too - if possible)
• [Feature Request]: Update modules not having a e2e/defaults and/or a e2e/waf-aligned test #4185
• Utilities (the following assumes to also update all scripts to be updated so they work with the folder structure of CARML (i.e., no avm folder)
  • Add Set-AVMModule utility (ref [Utilities] Introduced Set-Module script #4067)
  • Update Set-ModuleReadMe and related scripts
  • Relocate PSRule & module.test.ps1 similar to AVM in the utilities/pipelines folder
  • Update module.test.bicep
  • Relocate template & script patterns similar to what we did in AVM (currently located in the modules/.shared folder

[eriqua]

To the question: I don't see any advantage in that effort, I'd suggest to keep all modules in the modules folder as they are right now.
We're not planning to introduce any ptn modules in CARML anyway, nor maintaining any constructs going forward

[AlexanderSehr]

Just thinking about the experience if a customer would want to onboard either. It would finally make sense of that 'constructs' thing. We can also push this back, but I think it's a reasonable use case. More to discuss ^^. I could see either argument

[eriqua]

@AlexanderSehr hence I guess we can now close this as well

[AlexanderSehr]

Hey @eriqua, I thought so too. The only reason I eventually didn't was that there are actually some points in here we would need to discuss for any upcoming CI updates, that is, the 2 tickboxes that are not yet checked 😄 However, as we'd presumably remember those anyways when we tackle the CI, we can of course also close it ... how much do we trust our memory?

[eriqua]

@AlexanderSehr we don't (trust our memory). However if you agree I'd be more keen to open those issues to be discussed separately and close this one, since its title may be misleading

[AlexanderSehr]

We can do that. I assigned the issue to the 'CI issues' milestone for the time being. And once we get around to actually approach the topic we can split it up. I just can't be bothered right now - but I'm sure with these comments down here, we'll know what to do ;)