The main issue I have seen is that the Hexbear database data and schema has diverged from upstream Lemmy. There is no direct migration path and one needs to be developed, to transform the Hexbear database and data back to the same schema as upstream Lemmy. Until that happens we cannot run the upstream Lemmy code with the Hexbear data.
Everything should build properly and run properly, @layla did some additional bits to finish it off, but if you have problems report them in the Element chat
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
In the same way that thexbear deviated from the official release of lemmy, minecraft mods will deviate you from the official release cycle of minecraft, and if you deviate too far (or one of your mods stops getting active development) then you get stuck in an old version with no way to upgrade due to dependence on custom/legacy code.
The main issue I have seen is that the Hexbear database data and schema has diverged from upstream Lemmy. There is no direct migration path and one needs to be developed, to transform the Hexbear database and data back to the same schema as upstream Lemmy. Until that happens we cannot run the upstream Lemmy code with the Hexbear data.
Hexbear has, for this very reason, inadvertently vindicated my outright refusal to use Minecraft mods and only play vanilla.
I only had a fixed amount of time that I was able to give to looking at Hexbear and the majority of it was spent fixing bit rot.
The docker image was not buildable out of the box, the build instructions were incorrect, etc etc.
By time I got it to the point where I could build and run the code locally, I was out of time.
https://git.chapo.chat/hexbear-collective/lemmy-hexbear/commits/branch/main/search?q=author%3Afootfaults
deleted by creator
Everything should build properly and run properly, @layla did some additional bits to finish it off, but if you have problems report them in the Element chat
deleted by creator
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
How?
In the same way that thexbear deviated from the official release of lemmy, minecraft mods will deviate you from the official release cycle of minecraft, and if you deviate too far (or one of your mods stops getting active development) then you get stuck in an old version with no way to upgrade due to dependence on custom/legacy code.