elastic / elastic/elastic-package
Remove tianon/true docker images by using "--wait" in docker-compose up commands
- Dominant language
- Go
- Stars
- 72
- Forks
- 141
- Avg merge
- 19h 42m
- Merged PRs (30d)
- 55
Description
Currently, it is used `tianon/true` images to be able to wait for the services to be ready. Usages of these images are in the docker compose scenarios:
- https://github.com/elastic/elastic-package/blob/0a5538dcd23769d618c40ef6de2f5241535870f4/internal/stack/_static/docker-compose-stack.yml.tmpl#L24
- https://github.com/elastic/elastic-package/blob/0a5538dcd23769d618c40ef6de2f5241535870f4/internal/stack/_static/serverless-docker-compose.yml.tmpl#L24
According to the documentation, these images could be used if `--wait` flag is used in `docker-compose up` commands (from `elastic-package stack up`):
- Documentation: https://docs.docker.com/reference/cli/docker/compose/up/
> --wait Wait for services to be running|healthy. Implies detached mode.
> --wait-timeout int Maximum duration to wait for the project to be running|healthy
**IMPORTANT**: These flags imply to be in detached mode (`-d`) , so it needs to be checked how this affects when this mode is not used.
Relates https://github.com/elastic/elastic-package/pull/1694
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with internal/stack/_static/docker-compose-stack.yml.tmpl and internal/stack/_static/serverless-docker-compose.yml.tmpl, then trace the docker-compose up commands used by elastic-package stack up. Check how --wait and its implied detached mode affect both existing execution paths. Done means the tianon/true image usages are removed and both scenarios still wait for services correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker-compose, go
- Domain
- cli, devops
- Issue type
- Refactor
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100