| layout | page_title | description |
|---|---|---|
docs |
Operation Execution |
This page documents how operations such as build, deploy, and release execute within Waypoint. This helps explain what components need access to what systems and how information flows within Waypoint. |
This content is part of the legacy version of Waypoint that is no longer actively maintained. For additional information on the new vision of Waypoint, check out this blog post and the HCP Waypoint documentation.
This page documents how operations such as build, deploy, and release execute within Waypoint. This helps explain what components need access to what systems and how information flows within Waypoint.
Operation execution in Waypoint always flows through three components: the client enqueues a job request with the server, the server assigns the job to a runner, and the runner executes the job and streams logs and output back to the server and the client through the server. We will show a diagram of this happening.
To improve the user experience, Waypoint simplifies what is required and automatically runs certain components as needed. We will cover all of these cases on this page.
The common case is using a CLI to execute an operation that is executed remotely, which causes the static runner to spawn an on-demand runner to execute your operation. This provides the most stable and performant way to use Waypoint.
For this style of execution, the CLI queues the job with the server, the server assigns the job to a runner, and the job executes it. The dotted boxes represent process boundaries (perhaps on different computers) and the white boxes are logical components within a single process.
In this mode, the CLI does not need to remain attached to the server after queueing the job. The CLI may exit and the job will continue executing in the background.
In some cases, you use a CLI directly with a Waypoint server where there is no standalone "static runner" processes running.
For this execution, the CLI transparently spins up a runner in-process. This runner registers with the server like any other runner process but advertises that it can only accept jobs that are directly assigned to it. The CLI queues a job with the server for the operation and directly assigns this to the runner it is running in-process. See the diagram below. The dotted boxes represent process boundaries (perhaps on different computers) and the white boxes are logical components within a single process.
The most limited scenario is using a CLI with no remote server. This is also known as "local mode" execution.
For this execution, the CLI transparently spins up both a runner and server in-process. The CLI then follows the standard pattern of queueing and executing a job, but this all happens within a single process boundary. The dotted boxes represent process boundaries (perhaps on different computers) and the white boxes are logical components within a single process.
