The dockerfile at https://git.chapo.chat/hexbear-collective/lemmy-hexbear/src/branch/main/docker/dev is meant to be for when you compile it and build it locally.
That's nice that someone has pushed the container images to that registry, so that you could pull them down, but that's not the point of that Dockerfile and docker-compose file.
Order doesn't matter, you need to build both hexbear-frontend and lemmy-hexbear to get a local environment.
Basically, there's no repository that just contains the docker-compose files and good instructions for how to build all the containers. It's sprinkled throughout the repositories, which is kind of bad, when they have these cross-repo dependencies. But I'm not willing/able to tackle that at the moment.
Like, they didn't use a tool like Helm, or frankly, make their docker-compose files modular enough to work for both local testing, and production (usually this is done via environment variables and templating) so that they work for both. Instead there's just copies of docker-compose files littered throughout the repos.
I do this kind of stuff for a living, but I can't force everyone to do things the right way.
So, that's an issue with the last command in the build_docker.sh where it tries to do a docker-compose up -d - which really it shouldn't do. Building a docker image and running/invoking docker-compose should be two different operations. I don't know why the docker-compose command is mixed in.
You're welcome. At some point after my $JOB quiets down, I will maybe go in and clean up the docker mess and replace it with my far more opinionated way of doing things, but with better documentation for people just getting started with the code. Because it should have a clear README and instructions for how to get things up and running, with no gotchas or mystery
The dockerfile at https://git.chapo.chat/hexbear-collective/lemmy-hexbear/src/branch/main/docker/dev is meant to be for when you compile it and build it locally.
That's nice that someone has pushed the container images to that registry, so that you could pull them down, but that's not the point of that Dockerfile and docker-compose file.
deleted by creator
Yes you also need to build the frontend https://git.chapo.chat/hexbear-collective/hexbear-frontend
deleted by creator
Order doesn't matter, you need to build both
hexbear-frontendandlemmy-hexbearto get a local environment.Basically, there's no repository that just contains the docker-compose files and good instructions for how to build all the containers. It's sprinkled throughout the repositories, which is kind of bad, when they have these cross-repo dependencies. But I'm not willing/able to tackle that at the moment.
Like, they didn't use a tool like Helm, or frankly, make their
docker-composefiles modular enough to work for both local testing, and production (usually this is done via environment variables and templating) so that they work for both. Instead there's just copies of docker-compose files littered throughout the repos.I do this kind of stuff for a living, but I can't force everyone to do things the right way.
deleted by creator
Order doesn't matter. They just both have to be built. You probably built the backend, and didn't finish/wait for the frontend.
deleted by creator
So, that's an issue with the last command in the
build_docker.shwhere it tries to do adocker-compose up -d- which really it shouldn't do. Building a docker image and running/invokingdocker-composeshould be two different operations. I don't know why thedocker-composecommand is mixed in.deleted by creator
You're welcome. At some point after my $JOB quiets down, I will maybe go in and clean up the docker mess and replace it with my far more opinionated way of doing things, but with better documentation for people just getting started with the code. Because it should have a clear README and instructions for how to get things up and running, with no gotchas or mystery