Skip to content

dev compose setup#1007

Open
TimMeissner wants to merge 5 commits intobeyond-all-reason:mainfrom
TimMeissner:feature/dev-docker-setup
Open

dev compose setup#1007
TimMeissner wants to merge 5 commits intobeyond-all-reason:mainfrom
TimMeissner:feature/dev-docker-setup

Conversation

@TimMeissner
Copy link
Copy Markdown
Contributor

@TimMeissner TimMeissner commented Feb 18, 2026

This PR introduces a docker compose dev environment for Teiserver so devs can run a full local stack (DB, SMTP, metrics, Grafana, Teiserver, and recoil-autohost) with minimal manual setup. Solves issue #988
I didn't test with podman, not sure if it is fully compatible

Highlights

  • Added docker-compose.dev.yml with:
    • teiserver, postgres, mailhog, victoriametrics, grafana
  • Added Dockerfile dev stage / target
    • Hot-reload capable (although performance on windows is really bad with the mounts)
  • Added entrypoint automation to:
    • wait for DB
    • run migrations
    • optionally seed fake data (task is now idempotent)
    • run Tachyon setup
  • Added Grafana datasource provisioning and VM scrape config for metrics development
  • Added Docker helper tasks to mise.toml and README usage docs.

Bootstrapping changes

  • mix teiserver.tachyon_setup now correctly uses TEI_DB_HOSTNAME for connection instead of defaulting to localhost always by requiring app.start
  • Refreshed matchmaking engine seed version to be more recent, thinking about making this env variable configurable

CI

  • Added workflow to build/push both release and dev Docker images to GHCR.
  • Added a similar workflow to recoil-autohost

Test video

SMTP / metrics

chrome_3HGyONiAEa.mp4

AI Disclosure

I used GPT 5.3-codex and Claude 4.6 Sonet & Opus, mostly for troubleshooting and generating boilerplate AND for the changes to the elixir code that is setting up data, this needs thorough review because i don't know much about elixir yet.

@TimMeissner TimMeissner changed the title docker compose setup to start tachyon stack dev compose setup Feb 18, 2026
@TimMeissner TimMeissner marked this pull request as ready for review February 21, 2026 13:01
Copy link
Copy Markdown
Collaborator

@geekingfrog geekingfrog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some additional notes:

  • slop machines put useless comments everywhere. Things like
# Set working directory
WORKDIR /app

This all useless garbage, please remove all useless comments that just say what the code is doing. Comments should be to explain the why, not the how. Unless very complex code.

  • Does the autohost automaticallly download engines? Personally, I would drop everything autohost related for now. That can be a different PR. One can still go rather far locally without a autohost setup.

  • the commit history is complete garbage and provide no useful info. Either squash everything into one commit (meh), or take some time and care to craft a meaningful commit history with nice commit message to help reviewer and archeologist who try to figure out the reasoning behind some code.

I haven't even try to run anything, there are too many things to fix first. Once it's in a better shape I'll give it a go.

with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's this github token? Where does that live?

Copy link
Copy Markdown
Contributor Author

@TimMeissner TimMeissner Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is autopopulated by github in actions/workflows, no need to set it up in any way.

push: true
tags: ${{ steps.tags.outputs.dev_tags }}
cache-from: type=gha,scope=dev
cache-to: type=gha,mode=max,scope=dev
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to push a dev version as well? I'm not convinced

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wanted to setup an environment for bar-lobby and to run the tachyon setup tasks etc. this dev image is necessary and it would be convenient if you didn't have to build it yourself there.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

speaking about bar-lobby, i personally would not want to drop the autohost stuff because that was the main driver for doing this. but if you prefer i can extract it to a 2nd pull request, let me know.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TimMeissner

https://github.com/thvl3/BAR-Devtools

Might accomplish some of the automated setup you need, I found it worked well enough for me to get bar-lobby working

Dockerfile.dev Outdated

# Install hex and rebar
RUN mix local.hex --force && \
mix local.rebar --force
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these 2 tools needed?

Copy link
Copy Markdown
Contributor Author

@TimMeissner TimMeissner Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i used other dockerfiles (e.g. the release Dockerfile) as inspiration and it is also installed there, afaik hex is a package manager for elixir that is used to install the dependencies and the other one is for native compiling some libraries? i'll test if it is really required to install it

Edit: went with a totally different approach and reused the main Dockerfile and just added a dev stage, should improve maintainability by a lot

Comment on lines +10 to +26
echo "Waiting for PostgreSQL..."
while true; do
set +e
CREATE_OUTPUT=$(mix ecto.create 2>&1)
CREATE_STATUS=$?
set -e

echo "$CREATE_OUTPUT"

if [ $CREATE_STATUS -eq 0 ] || echo "$CREATE_OUTPUT" | grep -qi "already exists"; then
break
fi

echo "PostgreSQL not ready yet, retrying..."
sleep 2
done
echo "PostgreSQL is ready"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is not the responsability of the container running teiserver to check postgres is there. If you want such dependency, compose is there for that.
Also, this is for dev, if teiserver cannot start because pg isn't available, the user can figure out what to do.


echo "Running migrations..."
mix ecto.migrate
echo "Migrations complete"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

teiserver already does that in the application code.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it does, but if the database is not setup i can't run tachyon setup steps.

README.md Outdated
For a quick local stack (Postgres, SMTP, metrics, Grafana, recoil-autohost, teiserver), use the compose setup in this repo.

- Linux/macOS: `./docker/start.sh`
- Windows (PowerShell): `./docker/start.ps1`
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditch this and just put the command to run.

README.md Outdated

The start scripts auto-select `podman` when present, otherwise `docker` (or honor `CONTAINER_RUNTIME` if set).

This starts `docker-compose.dev.yml`, builds the `teiserver` dev image, runs migrations, and sets up fake data plus tachyon OAuth apps.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop this, it's going to fall out of sync. "This setup and starts everything that you should need for local dev" is enough.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you want to push dev images? I would drop the entire thing

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for bar-lobby so you can run one command and have a working setup.

@default_autohost_bot_name "tachyon-autohost"

defp autohost_bot_name,
do: System.get_env("AUTOHOST_BOT_NAME") || @default_autohost_bot_name
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop that, just hardcode the entire thing. If someone needs a different name/bot, they can do that by themselves.

@TimMeissner
Copy link
Copy Markdown
Contributor Author

TimMeissner commented Feb 22, 2026

Some additional notes:

  • slop machines put useless comments everywhere. Things like
# Set working directory
WORKDIR /app

This all useless garbage, please remove all useless comments that just say what the code is doing. Comments should be to explain the why, not the how. Unless very complex code.

  • Does the autohost automaticallly download engines? Personally, I would drop everything autohost related for now. That can be a different PR. One can still go rather far locally without a autohost setup.
  • the commit history is complete garbage and provide no useful info. Either squash everything into one commit (meh), or take some time and care to craft a meaningful commit history with nice commit message to help reviewer and archeologist who try to figure out the reasoning behind some code.

I haven't even try to run anything, there are too many things to fix first. Once it's in a better shape I'll give it a go.

sorry i am used to squashing on merge commit so i usually don't write meaningful commit messages. i'll invest some time to improve it and keep it in mind for the future. Thanks for the thorough code review!

Autohost will download engines automatically soon, once the PR is merged. I'll split the autohost stuff to a seperate PR to simplify it.

@TimMeissner TimMeissner marked this pull request as draft February 22, 2026 22:33
…or dev and release to github registry. dev image is published so it can be used by other repos like bar-lobby to start a local environment quickly
…s by adding additional env variables and default values to the config
…server - clean up postgres installation from mise.toml and adjust default env variables for smtp integration
@TimMeissner TimMeissner force-pushed the feature/dev-docker-setup branch 2 times, most recently from d479062 to 4ff9f9f Compare February 23, 2026 19:30
@TimMeissner TimMeissner marked this pull request as ready for review February 23, 2026 20:49
…asks to run in docker contexts, make fake generation task idempotent
@TimMeissner TimMeissner force-pushed the feature/dev-docker-setup branch from 4ff9f9f to 9aaaa7c Compare February 25, 2026 20:20
Copy link
Copy Markdown
Collaborator

@geekingfrog geekingfrog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one last thing I'd like to see is putting everything in the same host network.
Because if I want to run some component, typically teiserver, on the host (with iex -S mix phx.server, which gives me a shell onto the running app, which is super handy), then things like victoriametrics don't work.
I tested that on linux and it works fine, but I'm not sure how/if that would work on windows, do you have any thoughts about that?

end

if already_has_data do
IO.puts("Demo data already present, skipping generation")
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: prefer Mix.shell().info()

@TimMeissner
Copy link
Copy Markdown
Contributor Author

I think one last thing I'd like to see is putting everything in the same host network. Because if I want to run some component, typically teiserver, on the host (with iex -S mix phx.server, which gives me a shell onto the running app, which is super handy), then things like victoriametrics don't work. I tested that on linux and it works fine, but I'm not sure how/if that would work on windows, do you have any thoughts about that?

Yeah i see that issue as well, the start scripts and accessing everything with the network ip would have solved that problem. I'll give it a thought and try some ideas.

@geekingfrog
Copy link
Copy Markdown
Collaborator

If there's no other way than the bash templating then so be it, but that seems rather convoluted tbh. Especially since we can make assumptions for a dev machine, like ports and whatnot.

@TimMeissner
Copy link
Copy Markdown
Contributor Author

i'll look at the remaining issues next week, didnt forget about it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: podman compose file for local development

4 participants