Script to generate Dockerfiles by version + Github Action integration

[AbcSxyZ]

I'm starting to think about a script to generate a Dockerfile for each Dogecoin Core release, and to have a way to update existing Dockerfiles/images when a template is edited, by using GitHub Action (GA) to automate Docker Hub tasks.
The goal here is to draft the script & the GA process.

The repository architecture would be the following, as defined in the related issue:

.
└── version
    ├── distro1
    │   └── Dockerfile
    └── distro2
        └── Dockerfile
└── version2
   ├── distro1
   ....

As I see it now, we can have 2 type of event :

GitHub change	Docker Hub changes
push on release	1 version pushed, 1 image per distro
update of templates	all version updated, for all distros

By reading GA documentation, I think it can be possible to achieve something like that 🤞.

Should we update all Dockerfiles and images when a template is modified ? Docker Hub do not handle versioning for images, and changes can break related programs. Docker official images do not use a version strategy, but we may have change they don't.

I'm not sure how intensively GA should automate stuff. Do we try to do the publication of a new version with a workflow on Dogecoin Core called on releases ? Depend on the previous question, but do we automate update of templates (and Dockerfiles), GA propagating the change & committing automatically, or should do a PR ? Alternatively, do we let human run the script, creating locally new files & PR the result.

Any idea, expectation about the script/GA ? Any limitation to this current suggestion ?

[AbcSxyZ]

Beginning of an implementation with PR #40 about Dockerfile templatization.

[georgeartem]

why would we want all versions? wouldn't it make better sense to have docker support for some version going forward like 1.14.7 or 1.14.9 or whatever - just make a choice on where the historical cutoff would be for unsupported versions

[georgeartem]

When a new core version is released, selecting what is determined to be the most stable/performant asset as determined by the testing completed during the release cycle and pulling that into your docker ci would reduce the complexity proposed here significantly.