Replies: 5 comments 25 replies
-
|
Not sure there is any point downgrading to 22.04 when the leaks afaik were related to transmission 3.0, no? |
Beta Was this translation helpful? Give feedback.
-
|
Definitely. Maybe that closes the discussion already 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, the current build times for new releases are really slow. My proposal is to move the TransmissionBuilder stage in the Dockerfile to it's own image that updates when transmission releases new versions. Decoupling this will speed up build times for the image release. You can automate updating the build image with an action that checks for new versions and auto bumps the image version (it would make the most sense to make the tags match the transmission version for simplicity) with renovate bot (supports github releases to check for new transmission versions https://docs.renovatebot.com/modules/datasource/github-releases/) when a new version is detected. So new builds of transmission only run when there's a new release. New image releases for this repo will be independent and only be installing dependencies, web ui's and adding the other scripts and components. the build image would be something haugene/transmission-build with it's own workflow to detect the new transmission releases and run independently of the image build for haugene/transmission-openvpn |
Beta Was this translation helpful? Give feedback.
-
|
please take a look at #2691 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks |
Beta Was this translation helpful? Give feedback.
-
|
It looks like the latest fixes on the main build workflow is good (it builds all 3 architectures for the rss and proxy), except for the main image since the haugene/transmission-builder image doesn't exist yet. Is there a way to manually trigger the builder workflow? The version check workflow is set to run hourly so if you wanted to downgrade upstream/transmission-version.txt to 4.0.3 (which should trigger a build), it should bump it 4.0.4 again and trigger another new build. probably should have put them in 2 different commits so it could have the new workflow before it starts checking for the version file |
Beta Was this translation helpful? Give feedback.
-
|
this should be it .. |
Beta Was this translation helpful? Give feedback.
-
|
right, it failed due to the file typo which has been fixed. are you able to re-run it so it uses the latest Dockerfile with the fix? I don't have permissions to the actions on the repo other than viewing the status/output. |
Beta Was this translation helpful? Give feedback.
-
|
ok, added a workflow_dispatch to the job and triggered it..
…On Mon, Sep 4, 2023 at 2:58 PM ksurl ***@***.***> wrote:
right, it failed due to the file typo which has been fixed. are you able
to re-run it so it uses the latest Dockerfile with the fix? I don't have
permissions to the actions on the repo other than viewing the status/output.
—
Reply to this email directly, view it on GitHub
<#2595 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7OFYWM7JHQ3DNJWW3H4BLXYVUXXANCNFSM6AAAAAAXIOQAX4>
.
You are receiving this because you were mentioned.Message ID:
<haugene/docker-transmission-openvpn/repo-discussions/2595/comments/6900953
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
oh yeah, could do artifact uploads as releases but that requires a separate repo to not clutter the main releases. committing non text files is not very efficient (it will essentially store each copy). I think the current solution works for now. |
Beta Was this translation helpful? Give feedback.
-
|
I think this one is the old workflow with matrix build? https://github.com/haugene/docker-transmission-openvpn/actions/runs/6078202126 may not be needed |
Beta Was this translation helpful? Give feedback.
-
|
looks like they're both canceled. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, thanks, must have accidentally cancelled both |
Beta Was this translation helpful? Give feedback.
-
|
you re-ran the one with the matrix platform build and it only pushed the arm build |
Beta Was this translation helpful? Give feedback.
-
|
When using separate builds , manifest has to be edited manually. |
Beta Was this translation helpful? Give feedback.
-
|
thanks, we were using buildx with the docker-build-push action. it seems building each platform separately with matrix multi-runner breaks the manifest. |
Beta Was this translation helpful? Give feedback.
-
|
current issue is related to this.. |
Beta Was this translation helpful? Give feedback.
-
|
ah I see it's a different issue (github related). may need to manually retrigger transmission build workflow as well since the latest runs that did get past the checkout step were unable to find the image for 4.0.4 on amd64, arm64 since only arm was pushed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the help!! Back on track now |
Beta Was this translation helpful? Give feedback.
-
Not quite yet. There is a little cleanup to do since the 5.1.1 pre release failed build and push now replaced 5 and 5.1 tags with only the arm or arm64 image on docker hub for rss, proxy and the main image. It needs a repush on either 5.1.0 or 5.1.1 or maybe 5.1.2 as a clean new version. |
Beta Was this translation helpful? Give feedback.
-
|
Wow what a difference on the new build time using the prebuilt transmission builder. 6-16min down from 3+ hours. For future version updates, I think all you need to do is change the image version in the main Dockerfile for haugene/transmission-builder. The other 2 workflows should automatically detect and build new images when transmission has an upstream release. I'll keep an eye on it when they do another release though that seems to be random. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This is kind of a follow up to #2469, #2590 and #2589 where we've been touching on issues like the choice of base image as well as build optimizations and issues. Even if this ends up as a conversation with myself, or just me and @pkishino I think it's good to have it in an open thread for transparency and later reference.
Short summaries of the past, present and future:
Past: We were Ubuntu based, then had a period of dual builds Ubuntu/Alpine before choosing to go with Alpine because of smaller image size and wanting to avoid supporting two versions in parallel. After a couple of years with that we went back to Ubuntu because we wanted stability instead of fast update of underlying packages and libraries. One example issue is #1861
Present: We went back to Ubuntu which meant we also un-intentionally downgraded Transmission to 2.94 from 3.00. This caused some issues but we stayed the course. In Ubuntu 22.04 we're back at 3.00 but that seems to cause memory leaks #2469. And now from version 5.0.0 of the image we're running Transmission 4.x anyways and we build it from source as part of the image build so we're not depending on support from the apt repositories.
Future: Right now we're not getting the best of any world I think. We're having memory issues on 22.04 and we have really slow build times due to us doing the Transmission builds ourselves. Alpine has a strong card on its hand with already having Transmission 4.0.3 in the
edge/communityrepo. I played around with it a bit and that's not straight forward either without basing the whole image on alpine:edge which probably will take us back to instability as we experienced before.I'm open for suggestions. But as we weigh our options I'm inclined to do a minor release 5.1 where we downgrade base image to ubuntu:20.04, and introduce caching in our docker builds to speed things up. Hopefully that makes it stable again and speeds up the average build time enough to live with. We won't downgrade Transmission so I think we're fine, people don't care too much about the version of openvpn, curl or any other library in the container.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions