docker images of most (historical) bitcoin core versions back to v0.2.0 in 2009

[mocacinno]

Suse released sles 15 SP7 technology preview images a couple days ago. These images are released for testing compatibility with new service packs and for POC's.

In the meantime, i created new branches (ending in _SP7) for every bitcoin core version in the github repo, and i have succesfully built each version on sles 15 SP7. The images were only uploaded into github's docker repo: https://github.com/mocacinno/bitcoin_core_docker/pkgs/container/mocacinno%2Fbitcoin_core_docker/versions?filters%5Bversion_type%5D=tagged

Everything builds, but nothing was tested... If you want to help out, feel free to pull some _SP7 images and try if you can run them. If not, let me know (or create a fork, fix the issue and create a pull request).

Only use _SP7 images for testing, do not use them in production. The _SP7 branches will be merged into their respective branches once SP7 is actually maintained!!! _SP7 branches will not be added to the documentation either, these branches will seize to exist once SP7 is actually released.

[mocacinno]

v29.0 was released... At least, the v29.0 tag was created on github, so i released it on my repo...

Since the last "official" announcement is still talking about v29.0  being @ rc3, i have not tagged v29.0 as "latest". If you implemented your container infrastructure to use the latest version, you'll still pull v28.1.
I would not recommand using v29.0 in production for the time being, just wait untill it's released officially and i've re-built the images (or you can rebuild them yourself on your own infrastructure if you want).

This being said, v29.0 changed it's build process, at the beginning it looked like a difficult task, but building v29.0 is actually easyer when it comes to dependencies than the previous versions... I no longer build prereqs like boost or BerkeleyDB manually, building all those prereqs is now one very simple extra step in the cmake build process.

Documentation is also updated.

As always: if you see something wrong, fork, edit and make a pull request (or raise an issue on github or in this thread)

[mocacinno]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again
• i rebuilt all images with the latest suse BCI, so the container images have the latest patches
• i tagged v29.0 as latest, since it seems stable
• i modified the documentation using nice badges, so in the future you can look at the documentation to find of when a certain version was last built, wether the build was succesfull and how big the image is... For example: v29.0 (latest) documentation
• eventough i made dockerfiles for sles 15 sp7, it's very likely the branches will never be merged. Suse just released sles 16 BCI's, so i guess i'll probably jump to sles 16 instead of 15 sp7 (16 will have much longer support)

[NotATether]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again

Wouldn't it make more sense for you to simply fork the repositories to your own github account instead of pointing it to someone else's?

Github has seemingly unlimited file storage, and short of a DMCA takedown, the files aren't going anywhere.[/list]

[mocacinno]

update:

• a repo used for older v0.2.x versions no longer exists, but the necessary packages were moved to other repo's, i modified all impacted Dockerfiles, everything builds again

Wouldn't it make more sense for you to simply fork the repositories to your own github account instead of pointing it to someone else's?

Github has seemingly unlimited file storage, and short of a DMCA takedown, the files aren't going anywhere.[/list]

Those are package repo's (not github repo's), some of them are Gb's of (binary) rpm packages, sometimes even providing regular patches. I'm not sure github would approve if i cloned those into a github repo

For github repo's, you do have a valid point, i should probably fork those, so i'm not longer depending on repo's that might be removed in the future. I'll put that one on my to-do list.