wait-for-message-action

A GitHub Action that runs the wait-for-message Python utility. A simple client server utility that blocks until a message is sent/received on a TCP/IP socket connection. This action is useful for synchronizing interdependent networked jobs.

wait

Bind the local ip address on a port and wait (i.e. block) for a message to be received, if no message is received within the designated timeout an error is raised.

send

Send a message to the ip address and port via a tcp socket connection, if no acknowledgement is received due to a socket error the message will be resent until maximum attempts waiting delay seconds between each attempt, if max attempts exceeded an error is raised.

Runs On

Note: This action is only meant to be run on self-hosted GitHub Action runners.

Capability	Compatible	Note
Docker Linux	yes	Requires Docker
Native Linux	yes	Requires Python > 3.7
Docker Windows	no	Non Supported
Native Windows	yes	Requires Python > 3.7

Inputs

Input	Description	Default	Required
command	The command to execute; wait or send		true
ip	For send; the IP address of the server. For wait the IP address that will be binded is 0.0.0.0		true
port	For send; the TCP port number of the server. For wait; the TCP port number to listen on		true
message	For send; the message to send. For wait; the message to wait for		true
delay	For send; the number of seconds to delay between retries	10	false
attempts	For send; the maximum retry attempts	60	false
timeout	For wait; the number of seconds to wait for message	900	false
use_container	Use Docker container for execution	false	false
shell	The shell to use	bash	false

Usage

Send

Send - Native Linux

name: Test Native Send
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-linux
    steps:
    - name: Send for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "send"
        ip: "192.168.1.184"
        port: 8080
        message: "ready to proceed"
        timeout: 60

Send - Docker Linux

name: Test Container Send
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-linux
    steps:
    - name: Send for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "send"
        ip: "192.168.1.184"
        port: 8080
        message: "ready to proceed"
        timeout: 60
        use_container: true

Send - Native Windows

name: Test Windows Send
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-windows
    steps:
    - name: Send for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "send"
        ip: "192.168.1.199"
        port: 8080
        message: "ready to proceed"
        timeout: 60
        shell: cmd

Wait

Wait - Native Linux

name: Test Native Wait
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-linux
    steps:
    - name: Wait for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "wait"
        port: 8080
        message: "ready to proceed"
        timeout: 60

Wait - Docker Linux

name: Test Container Wait
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-linux
    steps:
    - name: Wait for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "wait"
        port: 8080
        message: "ready to proceed"
        timeout: 60
        use_container: true

Wait - Native Windows

name: Test Windows Wait
on: workflow_dispatch
jobs:
  test:
    runs-on: self-hosted-windows
    steps:
    - name: Wait for a Message
      uses: soda480/wait-for-message-action
      with:
        command: "wait"
        port: 8080
        message: "ready to proceed"
        timeout: 60
        shell: cmd

Examples

Synchronize Jobs

A Job depends on another Job.

Two self-hosted runners A and B.

Task-B1 depends on Task-A1 completing, thus add a Wait Job before Task-B1 that will wait/listen for a "Ready to Proceed" message, also add a Send Job after Task-A1 that will send the "Ready to Proceed" message to B.

Likewise, Task-A2 depends on Task-B1 completing, thus add a Wait Job before Task-A2 that will wait/listen for a "Ready to Proceed" message, also add a Send Job after Task-B1 that will send the "Ready to Proceed" message to A.

The Send Jobs require the IP address of the runner that the message will be sent to, thus the first Jobs are to acquire the IP addresses of the respective self-hosted runners.

Example Code

Synchronize steps within Jobs

A step within one Job depends on a step within another Job.

This example is essentially the same as above, except dependencies are between steps within Jobs. The same logic applies, the wait and send tasks are defined within the steps of the Jobs.

Example Code