Check and rebuild image on dependency update

[dgcampea]

Before creating this request I have:

REQUIRED

• Read through the pinned issues for related problems
• Searched for similar provider issues and container issues
• Read the documentation, especially the troubleshooting section and FAQ
• Tried to add as much relevant information to the request as possible
• Agreed that my issue will be closed if I do not follow this template and will remain closed until I complete the template

Is your feature request related to a problem? Please describe.

REQUIRED

Images are not being rebuilt when dependent upstream packages get new releases (such as Flood).

docker-transmission-openvpn/Dockerfile

Line 10 in d7e7a24

&& echo "Install Flood for Transmission" \

Describe the solution you'd like

REQUIRED

Automatic rebuilding of images when dependencies get new releases.

Describe alternatives you've considered

REQUIRED

Fix at CI level

Additional context

Optional

<placeholder for optional>

[pkishino]

while I understand the wish for always up-2-date packages, this is not really viable nor efficient, as automatic updates such as this could lead to build problems or unexpected issues..
EDIT: I realised that the 4 guis that we pull, two havent had any updates in years.. the other two we pull latests when a new image is built. I honestly don't think this is the right way as this could introduce unwanted side-effects.
@haugene What do you think? should we pin to the current latest release and then for future update the version based on newer releases?

[dgcampea]

For Flood at least, every commit results in a new release (johman10/flood-for-transmission#77). Not having it updated in a "regular" fashion risks missing out features and bug fixes (as well as its dependency updates since it uses dependabot).
See: johman10/flood-for-transmission#67

EDIT: I realised that the 4 guis that we pull, two havent had any updates in years.. the other two we pull latests when a new image is built. I honestly don't think this is the right way as this could introduce unwanted side-effects.

How about having some sort of bot or mechanism that automatically tracks upstream releases and opens PRs?
This would require using release tags instead of using the latest tarball though.

[dgcampea]

@pkishino Should this be re-opened until the concerns at #1832 (comment) are solved?

[pkishino]

Hmm, not sure why I closed this..

[pkishino]

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates
this looks usable

[ksurl]

What about adding an environment variable to enable checking and downloading the latest version on start.

You can do this right now with the openvpn-pre-start.sh script manually while waiting for this to be added

[dgcampea]

riable to enable checking and downloading the latest version on start.

You can do this right now with the openvpn-pre

Having it download every time the container gets created seems wasteful and doesn't seem to be in line with how containers should handle their dependencies. Having it baked into the image is the correct way to go.

[haugene]

Hmm. Do we have to trigger on upstream stuff? While very precise it's probably also a more complex solution. Could we just run once per week and say that's good enough? Open for other solutions as well 👍

[pkishino]

@johman10 i know you use the bot in your repo, care to give us some advice please?

[dgcampea]

Could we just run once per week and say that's good enough?

Having it weekly updated works for me.

@johman10 i know you use the bot in your repo, care to give us some advice please?

I took a look before at this and afaik, the bot would have to rewrite the Dockerfile which is something it doesn't do. A custom Github action that triggers some scripting + awk/sed magic might work here.

[johman10]

Not sure if I can add much here. I am not an export on Github releases and how to cut them properly. I came up with the current solution since I didn't know any better but have since learned about sementic releases with Github Actions.

That to the side, I can explain how it works for me now. As you can see in the Github actions for releases that I depend on the third party action GitHub Automatic Releases. This in my eyes is a pretty simple Github API integration that will push certain files to a release you indicate. It took some tinkering to get it to work as it does now but overall it was pretty straightforward.

On that same note, Github Actions support time based runs: https://docs.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events. This means you can trigger a Github Action at the interval of your liking to patch a new version of the Docker image if you want.

[notoriousjere]

Hello! I just wanted to comment here for visibility again. @johman10 recently made an update to Flood that I was interested in seeing in this image. I think @haugene that your suggestion of a 1x/week rebuild would make sense, as long as it's easy to implement.