OpenDCT in the Community Applications

[stuckless]

I've added OpenDCT (Fuzzy's Docker) to the Community Applications... so if you are in unRAID you can search and install it, just like, SageTV Server.

[Fuzzy]

Originally Posted by stuckless

I've added OpenDCT (Fuzzy's Docker) to the Community Applications... so if you are in unRAID you can search and install it, just like, SageTV Server.

Thanks.. I never did find a proper guide on how to do that.

[stuckless]

Originally Posted by Fuzzy

Thanks.. I never did find a proper guide on how to do that.

Yeah, there's no real guide (from what I can tell)... but now, if you do create other dockers, you can simply add them to my unRAID repo and they'll get picked up in CA.

https://github.com/stuckless/unRAID

[Fuzzy]

Originally Posted by stuckless

Yeah, there's no real guide (from what I can tell)... but now, if you do create other dockers, you can simply add them to my unRAID repo and they'll get picked up in CA.

https://github.com/stuckless/unRAID

Okay, cool. I was thinking of actually trying to merge the docker build into the OpenDCT source, so when a version is pushed of openDCT, it pushed a new docker image, thus eliminating the 'update on start' mechanic, and transitioning to using unRAID's in-UI 'Update' mechanic instead. Any thoughts about the pros and cons of this, and if it should be done that way for SageTV as well? Seems the Docker container at this point should really be treated as just another build of sage, especially since we, as a community, seem to treat it as the 'main' dist now.

[stuckless]

Originally Posted by Fuzzy

Okay, cool. I was thinking of actually trying to merge the docker build into the OpenDCT source, so when a version is pushed of openDCT, it pushed a new docker image, thus eliminating the 'update on start' mechanic, and transitioning to using unRAID's in-UI 'Update' mechanic instead. Any thoughts about the pros and cons of this, and if it should be done that way for SageTV as well? Seems the Docker container at this point should really be treated as just another build of sage, especially since we, as a community, seem to treat it as the 'main' dist now.

For opendct, that's likely a good solution, and could likely work for sagetv as well. I'm sort of mixed about it... unless I had it fully integrated into the build cycle, then I'd probably not do it for sagetv. As it sands, I'm already a bottleneck for getting sagetv build out and it would further bottlenecked if I were having to manage the container update at the same time as the build.

Also, sagetv is not well structured for docker, which is why the "files" are stored outside the container. I think ideally, there should be a start "bin" area that in the container, and all other things like properties, plugins, etc, are stored outside the container. That's hard to do today with sagetv.

[EnterNoEscape]

Originally Posted by stuckless

For opendct, that's likely a good solution, and could likely work for sagetv as well. I'm sort of mixed about it... unless I had it fully integrated into the build cycle, then I'd probably not do it for sagetv. As it sands, I'm already a bottleneck for getting sagetv build out and it would further bottlenecked if I were having to manage the container update at the same time as the build.

Also, sagetv is not well structured for docker, which is why the "files" are stored outside the container. I think ideally, there should be a start "bin" area that in the container, and all other things like properties, plugins, etc, are stored outside the container. That's hard to do today with sagetv.

I believe there are additional complications for SageTV because some plugins make assumptions about where things will be. We already saw what happened just by changing the class paths a little. I'm not sure I want to see what happens when we move all of the configuration away from the binary. If I thought it could be done without significant breakage, I would be willing to put in the time to separate everything.

[stuckless]

Originally Posted by EnterNoEscape

I believe there are additional complications for SageTV because some plugins make assumptions about where things will be. We already saw what happened just by changing the class paths a little. I'm not sure I want to see what happens when we move all of the configuration away from the binary. If I thought it could be done without significant breakage, I would be willing to put in the time to separate everything.

Yes, I feel the same way

[Fuzzy]

I certainly wouldn't recommend making the docker image a part of the core distribution if it wasn't part of the actual build, but I do believe there are docker addons for gradle, so it should be able to be automated. I just don't know enough about gradle, or building in general, to know for sure if it's what is needed.