Flood: Create a docker hub automated build

[penx]

• Create a docker hub account https://hub.docker.com
• Link to jfurrow GitHub account https://hub.docker.com/account/authorized-services/
• In Docker Hub menu, select Create -> Create Automated Build
• Select GitHub then select jfurrow/flood
• In the project builds settings, trigger a build

I've created one here, but it's pointed at a fork, think a project admin would need to set this up so it rebuilds on every commit:

https://hub.docker.com/r/penx/flood/

[jfurrow]

Okay, I've finally realized why Docker containers are good (more or less), and I want to recommend that Flood users run Flood in a Docker container. But I don't know where to start, exactly, or what the etiquette is.

I've been using @Wonderfall's Dockerfile for development, which contains both rTorrent and Flood, and it's working well for me. Is this good practice?

I'll read more of the docs...

[0xcaff]

@jfurrow, You can start by following the directions provided by @penx or the tutorial in the docker docs. Once this is done, users can run flood with:

docker run -e RTORRENT_SCGI_HOST=w.x.y.z -p 3000:3000 jfurrow/flood

This is nice because users don't have to build anything locally.

The convention is to generate a docker container for each service (one for rtorrent, one for flood) and connect them together at runtime using something like docker-compose.

I just created a minimal container for rtorrent for linking to this when it is ready.

[noraj]

rTorrent and flood must not be in the same container. A container for each is a good practice. Because you can reuse the same rTorrent container for ruTorrent for example.

[deed02392]

I concur with @noraj1337, I would be happy with a straight up automated build of this repo which is exactly what you'll achieve if you follow the suggestions verbatim.

I have written an AWS lambda script to automatically trigger new Docker Hub builds of release tags for another GitHub repo I'm not the owner of. I could use that for this repo for now if anyone is interested. This would address that out of date issue your fork will create, @penx.

[noraj]

@deed02392

Why it is recommended to run only one process in a container?

But thanks to Docker compose you will be able to build a multi-container Docker applications. So just build a flood alone container + a config file for docker compose where you tell to pull the flood container + an already existing rTorrent container. This will be as easy for you to build if not even easier, it will be as automatic and as easy to deploy.

[deed02392]

@noraj1337 even easier than what? I was agreeing with you .

[0xcaff]

I believe there was someone else in this conversation who deleted their comments.

[noraj]

@deed02392 My bad if I misunderstood, I'm not a native english speaker.

[cron410]

I can assist with this. I actually have one set up already since I do not have access to your github account. I did it the hard way by creating a 1:1 fork on my github with backstroke to automate pull requests. https://hub.docker.com/r/themetabay/flood/

What you want to do is set up a docker hub account, connect your github account with this page: https://hub.docker.com/account/authorized-services/ then use the menu on the top right to create an Automated Build here: https://hub.docker.com/add/automated-build/jfurrow/ and point it at the docker-flood github repo.

[codevski]

+1 this would be awesome to have.

[penx]

@jfurrow any chance you could do this? Hopefully the 5 steps in my original ticket should only take you 5 minutes - let me know if not, or you have any questions. Happy to help, but as mentioned you need to be an admin of this repo to set this up.

[deed02392]

Happy to jump on a phone call with you too @jfurrow if need be

[noraj]

@deed02392 maybe catch him on discord

[Sparticuz]

Any movement on this?

[cron410]

I would recommend my repo, but it seems backstroke has stopped sending pull requests to my 1:1 copy of this repo.

[noraj]

Pushing docker images on dockerhub automatically must be done with git/release tags with is a problem since flood has only 1 version right now. See this point no versioning (only 1 release) from #712 and this issue Make a new github release, the current release is quite old. #734

[gytis-ivaskevicius]

Webhook could be set up on any new commits to the master branch. Wouldn't doing it this way solve point no versioning (only 1 release)

[noraj]

@WithoutCaps true but I don't see it as a good idea, because the master branch may be unstable but there can be a release docker image and a git based docker image.

[SerialVelocity]

@noraj Having an unstable build is quite a bit better than nothing. Best option would ofc be start tagging releases every so often just so people know whether there are large features/improvements/bugfixes in the next release they take and can upgrade accordingly but that does put more load on @jfurrow.

If the tag is called develop instead of latest it may help inform people that it may break suddenly.

Currently, people just pull a random docker image from dockerhub which is just a random commit of flood...

[deed02392]

@jfurrow for comment

[noraj]

Anyway @jfurrow used to spend like 1/2 every 3 months on the project those last years so better create the automated build (CI files and all) for him and make a PR so he have only to merge it and open a docker hub account else I don't think it will happen.

[jfurrow]

so better create the automated build (CI files and all) for him and make a PR so he have only to merge it and open a docker hub account

This is spot-on! Y'all should submit a PR with what you want.

[noraj]

What I was trying to say is : "Don't wait for the feature to come if you don't plan to dev it yourself".

[penx]

This is spot-on! Y'all should submit a PR with what you want.

This ticket doesn’t require any dev work else I would have done it a couple of years ago when I raised it.

It requires 5 minutes of @jfurrow’s time to follow the steps in my original ticket.

Unfortunately only @jfurrow can do this as setup requires admin access to the repo, as per my previous comment.

[penx]

Pushing docker images on dockerhub automatically must be done with git/release tags

This certainly wasn’t the case when I opened this ticket 2 years ago. I was able to set this up on a fork just fine

[jfurrow]

Ahh I see...

[cron410]

@jfurrow the steps have changed since last year, but you would still only have to do this once. I see you already have an account. First hurdle over.

Step 1: Go here: https://cloud.docker.com/settings/#container-source-providers
click Connect or click Re-link if the Connect button is missing.

Step 2:
Go here: https://cloud.docker.com/repository/create
Name it, scroll down and click the Github icon, make selections in the 2 dropdowns. Click Create and Build

Done. That's it. Then you would be able to close this issue.

[jfurrow]

Thanks @cron410! I'm pretty sure I created the docker build at https://cloud.docker.com/repository/registry-1.docker.io/jfurrow/flood-ui... could you verify before I close this issue?

[SerialVelocity]

The link to your docker image is here:
https://hub.docker.com/r/jfurrow/flood-ui

It's visible and was successfullly built but I haven't tested it.

[Sparticuz]

It looks like that container is working. The only thing I changed in my docker compose file was switching out this line build: https://github.com/Flood-UI/flood.git with image: jfurrow/flood-ui

However, because I use FLOOD_BASE_URI, each time I update the container I need to run the following code to recompile flood's static assets.
docker exec flood_container npm install docker exec flood_container npm audit fix docker exec flood_container npm run build docker exec flood_container npm prune --production docker restart flood_container

This might be it's own issue, but I see two solutions to automate this.

• Flood's container startup detects a change or value in that env var and rebuilds itself.
• Because I use watchtower to update my containers, use the feature in https://github.com/containrrr/watchtower/pull/351 to have watchtower run the commands.

[noraj]

@Sparticuz maybe it is possible to automate this with docker compose.

[cron410]

@jfurrow since @Sparticuz tested, the automated build is working. No further action is necessary as all future changes will be made here on Github by changes to the Dockerfile. I think we can close this one out.

[jfurrow]

Thanks!