This PR adds docker build args for controlling the Subsonic binary download and refactors the download logic, such that docker images for multiple specific Subsonic versions can be built more easily.
Also, this adds a safety check on the downloaded binary, by comparing the SHA-256 of the downloaded archive against the specified value.
These args can be used to build multiple images with different subsonic versions like so:
Available versions and SHA-256 values can be taken from the official Subsonic download page.
This does intentionally not implement automatic installation of the latest released binary.
The rationale is, that even for older subsonic versions it must be possible to build updated images (e.g. for receiving distribution package updates, fixing bugs, etc.).
Therefore, this PR provides the foundation for building the image for any Subsonic version from a simple CI script as shown above.
However, since releases (as you have already said) are infrequent and to avoid instabilities due to changing contents of the checksum file, I'd recommend just setting up a simple CI job with hardcoded values for known and supported versions.
Not knowing anything about you CI infrastructure, an example job for e.g. Gitlab CI could look something like this:
This PR adds docker build args for controlling the Subsonic binary download and refactors the download logic, such that docker images for multiple specific Subsonic versions can be built more easily.
Also, this adds a safety check on the downloaded binary, by comparing the SHA-256 of the downloaded archive against the specified value.
These args can be used to build multiple images with different subsonic versions like so:
Available versions and SHA-256 values can be taken from the official Subsonic download page.
This does intentionally not implement automatic installation of the latest released binary.
The rationale is, that even for older subsonic versions it must be possible to build updated images (e.g. for receiving distribution package updates, fixing bugs, etc.).
Therefore, this PR provides the foundation for building the image for any Subsonic version from a simple CI script as shown above.
If desired, the file containing all official checksums could be used to build images for all versions with some bash-acrobatics like this:
... or for building just the latest version with something like this:
However, since releases (as you have already said) are infrequent and to avoid instabilities due to changing contents of the checksum file, I'd recommend just setting up a simple CI job with hardcoded values for known and supported versions.
Not knowing anything about you CI infrastructure, an example job for e.g. Gitlab CI could look something like this:
Please let me know what you think about these changes.