wait-for

./wait-for is a script to wait for another service to become available.

1,963

406

1,963

View on GitHub

Top Related Projects

wait-for-it

9,716

Pure bash script to test and wait on the availability of a TCP host and port

docker-compose-wait

1,686

A simple script to wait for other docker images to be started while using docker-compose (or Kubernetes or docker stack or whatever)

dockerize

5,097

Utility to simplify running applications in docker containers

Quick Overview

The eficode/wait-for project is a simple and lightweight command-line tool that allows you to wait for a specific condition to be met before continuing with your script or program. It can be used to wait for a TCP connection, HTTP response, or a file to exist.

Pros

Simplicity: The tool is easy to use and has a straightforward command-line interface.
Flexibility: It supports a variety of conditions to wait for, including TCP connections, HTTP responses, and file existence.
Cross-platform: The tool is written in Go and can be used on multiple operating systems, including Linux, macOS, and Windows.
Lightweight: The tool has a small footprint and does not require any external dependencies.

Cons

Limited Functionality: The tool is focused on a specific set of use cases and may not be suitable for more complex scenarios.
No Scripting Support: The tool does not provide any scripting capabilities, so you may need to integrate it into your own scripts or programs.
No Monitoring: The tool does not provide any monitoring or logging capabilities, so you may need to rely on external tools for that.
No Error Handling: The tool does not provide any advanced error handling, so you may need to handle errors manually in your own code.

Code Examples

Here are a few examples of how you can use the eficode/wait-for tool:

Wait for a TCP connection:

wait-for -t 10 tcp://example.com:80

This command will wait for up to 10 seconds for a TCP connection to example.com:80 to be established.

Wait for an HTTP response:

wait-for -t 10 http://example.com

This command will wait for up to 10 seconds for an HTTP response from http://example.com.

Wait for a file to exist:

wait-for -t 10 file://path/to/file.txt

This command will wait for up to 10 seconds for the file file.txt to exist in the specified path.

Wait for multiple conditions:

wait-for -t 10 tcp://example.com:80 http://example.com file://path/to/file.txt

This command will wait for up to 10 seconds for all three conditions to be met: a TCP connection to example.com:80, an HTTP response from http://example.com, and the existence of the file file.txt in the specified path.

Getting Started

To use the eficode/wait-for tool, you can download the pre-built binary from the project's GitHub releases page. Alternatively, you can build the tool from source by following these steps:

Install Go on your system.
Clone the eficode/wait-for repository:

git clone https://github.com/eficode/wait-for.git

Change to the project directory and build the tool:

cd wait-for
go build -o wait-for

(Optional) Move the wait-for binary to a directory in your system's PATH to make it accessible from anywhere.

Once you have the wait-for binary, you can use it in your scripts or programs to wait for specific conditions to be met before continuing.

Competitor Comparisons

wait-for-it

9,716

Pure bash script to test and wait on the availability of a TCP host and port

Pros of wait-for-it

More feature-rich, supporting both TCP and HTTP checks
Offers more command-line options for flexibility
Written in Bash, making it more portable across different systems

Cons of wait-for-it

Larger codebase, potentially more complex to maintain
May have slower execution due to being a Bash script
Requires Bash to be installed on the system

Code Comparison

wait-for-it:

#!/usr/bin/env bash
# Use netcat to check for open port
nc -z "$HOST" "$PORT" > /dev/null 2>&1
result=$?

wait-for:

#!/bin/sh
# Use netcat to check for open port
nc -z "$host" "$port"
result=$?

The main difference in the code snippets is that wait-for-it uses Bash-specific syntax, while wait-for uses POSIX-compliant shell script syntax. This makes wait-for more portable across different systems that may not have Bash installed.

Both scripts use the nc (netcat) command to check if a port is open, but wait-for-it redirects output to /dev/null, while wait-for doesn't. This might affect the verbosity of the output in certain situations.

Overall, wait-for-it offers more features and flexibility, while wait-for focuses on simplicity and portability. The choice between the two depends on specific use cases and system requirements.

docker-compose-wait

1,686

A simple script to wait for other docker images to be started while using docker-compose (or Kubernetes or docker stack or whatever)

Pros of docker-compose-wait

Written in Rust, offering potential performance benefits
Supports multiple hosts and ports simultaneously
Provides more detailed logging and customization options

Cons of docker-compose-wait

Larger binary size due to Rust compilation
May have a steeper learning curve for users unfamiliar with Rust
Requires separate installation or inclusion in Docker images

Code Comparison

wait-for:

#!/bin/sh
TIMEOUT=15
QUIET=0

usage() {
  echo "Usage: $0 [OPTIONS] HOST:PORT [HOST:PORT]..."
  exit 1
}

docker-compose-wait:

use std::env;
use std::net::{TcpStream, ToSocketAddrs};
use std::time::{Duration, Instant};

fn main() {
    let args: Vec<String> = env::args().collect();

Both projects aim to solve the problem of waiting for services to be ready in containerized environments. wait-for is a simple shell script, making it lightweight and easy to integrate into existing Docker images. docker-compose-wait offers more features and potentially better performance but comes with a larger footprint. The choice between the two depends on specific project requirements, such as the need for advanced features, performance considerations, and ease of integration.

dockerize

5,097

Utility to simplify running applications in docker containers

Pros of dockerize

More feature-rich, offering templating and log output in addition to waiting for services
Supports multiple protocols (TCP, HTTP, HTTPS) for checking service availability
Written in Go, potentially offering better performance and cross-platform compatibility

Cons of dockerize

Larger binary size due to additional features
May be considered "overkill" for simple use cases where only waiting functionality is needed
Slightly more complex to use due to its broader feature set

Code comparison

wait-for:

#!/bin/sh
./wait-for host:port -- command

dockerize:

dockerize -wait tcp://host:port -timeout 10s command

Key differences

wait-for is a simple shell script, while dockerize is a compiled Go binary
wait-for focuses solely on waiting for services, while dockerize offers additional functionality
dockerize provides more options for configuring the wait behavior, such as timeout and retry intervals

Both tools serve the purpose of ensuring services are ready before executing commands, but dockerize offers a more comprehensive solution at the cost of increased complexity and size. The choice between the two depends on specific project requirements and preferences for simplicity versus feature richness.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

wait-for

Wait for another service to become available

Example usage Â· Submit a PR

./wait-for is a script designed to synchronize services like docker containers. It is sh and alpine compatible. It was inspired by vishnubob/wait-for-it, but the core has been rewritten at Eficode by dsuni and mrako.

The easiest way to get started using this tool is to include the wait-for file as part of your project. Then call this script as part of any automation script.

Usage

Locally

Download the wait-for file, either the latest from master or for a specific version check out the Releases-page.

With the file locally on your file system, you can directly invoke it.

./wait-for host:port|url [-t timeout] [-- command args]
  -q | --quiet                        Do not output any status messages
  -t TIMEOUT | --timeout=timeout      Timeout in seconds, zero for no timeout
                                      Defaults to 15 seconds
  -v | --version                      Show the version of this tool
  -- COMMAND ARGS                     Execute command with args after the test finishes

Alternatively, you could download the script and pipe it into sh:

$ wget -qO- https://raw.githubusercontent.com/eficode/wait-for/v2.2.3/wait-for | sh -s -- google.com:80 -- echo success

Note: When using the latter option, make sure to pin the version by commit hash. Future releases could introduce non-backwards compatible changes and leaves you vulnerable to malicious users modifying this script in the future (as has e.g. happened with Codecov).

GitHub Actions

Similarly to how we piped the script into our shell covered in local usage, we can also use this in GitHub Actions, like so:

      - name: Wait for the database to start
        run: wget -qO- https://raw.githubusercontent.com/eficode/wait-for/$WAIT_FOR_VERSION/wait-for | sh -s -- localhost:5132 -- echo "Database is up"
        env:
          WAIT_FOR_VERSION: 4df3f9262d84cab0039c07bf861045fbb3c20ab7 # v2.2.3

Docker

We also publish a container to Docker Hub at eficode/wait-for, where we publish under the tag latest what's in master and tags for each release. (Only tags newer van v2.2.3 are available.) You can use the container like this:

$ docker run --rm eficode/wait-for google.com:80 -- echo success
success

Note: We will refrain from changes in the container we are publishing from triggering releases, as our primary distributable remains the script itself. One exception might be urgent security fixes.

Examples

To check if www.eficode.com is available:

$ ./wait-for www.eficode.com:80 -- echo "Eficode site is up"
Eficode site is up

To wait for database container to become available:

version: "3"

services:
  db:
    image: postgres:9.4

  backend:
    build: backend
    command: sh -c './wait-for db:5432 -- npm start'
    depends_on:
      - db

To check if https://www.eficode.com is available over HTTPS:

$ ./wait-for https://www.eficode.com -- echo "Eficode is accessible over HTTPS"
Eficode is accessible over HTTPS

To wait for your API service to become available:

version: "3"

services:
  api:
    image: nginx

  tests:
    build: .
    command: sh -c './wait-for http://api -- echo "The api is up! Let's use it"'
    depends_on:
      - api

Testing

Testing is done using bats, which we install using npm.

For reproducibility, we run our tests inside Docker, such that we have control over the version of bash we're testing against.

docker build --target test-env --tag wait-for .
docker run --rm -t wait-for

Contributing

When creating PRs, please style your commit messages according to conventional commit, you can use a tool like commitizen to guide you. We will automatically infer the changelog from your commits. Alternatively, we can squash all commits when merging and update the commit message.

This project strongly prefers maintaining backwards compatibility, therefore some obvious "fixes" might not be accepted.

Also, please include or update the test cases whenever possible by extending wait-for.bats.

Note

Make sure netcat is installed in your Dockerfile before running the command if you test over plain TCP.

RUN apt-get -q update && apt-get -qy install netcat

https://stackoverflow.com/questions/44663180/docker-why-does-wait-for-always-time-out

If you are connecting over HTTP, then you will need to have wget available.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot