[Enhancement]: Some ideas for testcontainers-go

[mmorel-35]

Proposal

There are several ideas I can see concerning testcontainers-go, some concerning modulegen, some concerning the CI/CD.

Modulegen

• extract mkdocs example.md file generation in /internal/mkdocs modulegen: generate md file inside internal/mkdocs #1543
• extract Makefile file generation in /internal/make modulegen: create internal/make #1537
• extract example.go and example_test.go file generation in /internal/module modulegen: create internal/module and internal/modfile #1539
• extract go.mod file generation in /internal/module and replace html/template with golang.org/x/mod/modfile to directly read from main go.mod modulegen: create internal/module and internal/modfile #1539
• Replace templates functions with Example attributes
• use github.com/spf13/cobra to handle the commands modulegen: use cobra instead of native golang flag #1550

CI/CD

• Provide code coverage to sonarcloud (starting with main module) chore(ci): enable code coverage on Sonarcloud #1518
• Generate sonar-project.properties per module/example ?
• Change dependabot updates schedule interval to "weekly" to address updates more frequently so it doesn't become an epic task every month ?
• Move Image of the example/module to a Dockerfile to be able to receive updates from dependabot ?
• trigger a go mod tidy on every module depending on the main one when it is modified

I'm much more focused on modulegen for the moment

[mdelapenya]

Change dependabot updates schedule interval to "weekly" to address updates more frequently so it doesn't become an epic task every month ?

We already had that schedule, and there were lots of updates, exhausting the free tier of our GH actions workers across the entire testcontainers organisation.

[mmorel-35]

I guess that at that time there was no groups for the updates. Would it helps smooth the process?
Another option would be to replace dependabot with renovate.

[mdelapenya]

Move Image of the example/module to a Dockerfile to be able to receive updates from dependabot ?

Regarding this, I'd say no, as we want to keep modules stable, at least until we have a real support matrix (which we do not have). Also moving to a Dockerfile-based module will force users to build the image again and again.

Just in case, I'm exploring updatecli for certain updates