Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker images build breaks too often #2374

Open
eikek opened this issue Nov 11, 2023 · 8 comments
Open

Docker images build breaks too often #2374

eikek opened this issue Nov 11, 2023 · 8 comments
Labels
docker All things regarding docker setup

Comments

@eikek
Copy link
Owner

eikek commented Nov 11, 2023

I'm not sure what to do about it yet, but I'm very tempted to just remove it. I don't use it anyways and it is taking too much of my time to maintain. The docker build breaks too often - it feels like every other week. It was fixed just a few days ago and it is failing again (probably because of some package dependency problem).

Maybe someone else wants to maintain it? It could also be a separate repo on the docspell org.

@eikek eikek added the docker All things regarding docker setup label Nov 11, 2023
@LightTemplar
Copy link

What if you will do it for releases only? It's still a very convenient way to use software.

@eikek
Copy link
Owner Author

eikek commented Dec 5, 2023

The problem are the releases. I don't care much about the snapshots, because it is in flux anyways. It can slow down releasing a lot. Often it is a boring task around chasing package problems (more often than not it's the ocrmypdf python tool). The images also need to be tested a bit. Unfortunately, this consumes much of my time, and I'm not using it myself. I think I'll move the docker things out in a separate repo. It can publish docker images and once it breaks maybe someone else can take care.

@LightTemplar
Copy link

I agree with this solution. Though, it would be interesting to know, if you have a statistics of Docspell installations. How big is the part, which goes onto docker?

@eikek
Copy link
Owner Author

eikek commented Jan 15, 2024

Unfortunately, I have no idea. I think it is a significant percentage, though. But I need to cut down time spent anyways.

@programmerq
Copy link
Contributor

I'd like to see the official image stick around.

I'd recommend building off a stable alpine release instead of an alpine edge snapshot. The underlying edge repo is a rolling release, and things can change inadvertently.

Part of a release process would include manually bumping the major alpine version base to the latest supported and working alpine version.

That's my suggestion on this problem. I think it'd be a lot smoother and be less prone to breaking.

@eikek
Copy link
Owner Author

eikek commented Jan 30, 2024

I did this in the past and it resulted in too much time spent hunting down alpine packages for that new version. So it only moves the annoying stuff to release time. And at the end I used to just stick with the version I had :)

@programmerq
Copy link
Contributor

Sticking with a major version of alpine as opposed to using an edge release will yield fewer breakages.

Alternatively, an Ubuntu LTS base would allow you to have a relatively unchanged base image for years. If you're open to that, I'm happy to work on an Ubuntu variant and open a PR.

@eikek
Copy link
Owner Author

eikek commented Jan 31, 2024

Ah thanks! I think I misunderstood. The idea was actually not to use "edge" but the latest stable release. So yes, this should be changed. I like your suggestion. If ubuntu is more stable, I would definitely prefer it, because I won't spend much time anymore on docker stuff myself :). As long as it builds I'm fine. When it breaks, I'll probably move it into a separate repo for others to maintain.

One little advantage could be that it is easier to publish new images after a fix to the image only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docker All things regarding docker setup
Projects
None yet
Development

No branches or pull requests

3 participants