hashicorp/waypoint

A tool to build, deploy, and release any application on any platform.

---

HashiCorp Waypoint Community Edition is no longer actively maintained. For additional information on the new vision of Waypoint, check out this blog post and the HCP Waypoint documentation.

---

Waypoint

• Website: https://www.waypointproject.io
• Tutorials: HashiCorp Developer
• Forum: Discuss

Waypoint allows developers to define their application build, deploy, and release lifecycle as code, reducing the time to deliver deployments through a consistent and repeatable workflow.

Waypoint supports a number of build methods and target platforms out of the box and more can be easily added via plugins:

• Cloud Native Buildpacks
• Docker
• Kubernetes
• AWS EC2 and ECS
• Azure Container Instances
• Google Cloud Run
• And many more...

Waypoint runs on Linux, Mac OS X, and Windows.

Please note: We take Waypoint's security and our users' trust very seriously. If you believe you have found a security issue in Waypoint, please responsibly disclose by contacting us at [email protected].

Quick Start

A quick start guide is available on HashiCorp Developer. You can also find tutorials which cover topics ranging from getting started guides to more advanced usage.

• Getting Started
• Introduction
• Installation
• Docker
• Kubernetes
• Nomad
• Waypoint UI
• AWS ECS
• Azure Container Instance
• Google Cloud Run

Documentation

Full, comprehensive documentation is available on HashiCorp Developer:

https://developer.hashicorp.com/waypoint/docs

Contributing

Thank you for your interest in contributing! Please refer to CONTRIBUTING.md for guidance.

Installing Dependencies

This repository contains a couple of different ways to automate installing the required Golang packages needed to build Waypoint locally. You can either use NixOS, or run make tools to setup the required packages.

Running the unit tests

To run the entire test suite, you'll want to ensure that you've brought up all the required containers used for testing. You can do this by leveraging the existing docker-compose.yml file that's in the root directory of this project:

$ docker-compose up

After running this, you should have a local Horizon container along with a few other services needed for running the tests:

$ make test

Running individual tests

If you don't want to run the entire test suite, you can just run a singe test with go. For example, if you wanted to run the tests ListInstances, you would run:

$ go test -run ListInstances -v ./internal/server/singleprocess

waypoint's Issues

Confusing/redundant "default is default" error message with `waypoint context`

My local installation got in a weird state and I ended up trying to play with contexts probably earlier than intended. Along the way I ran into this error message:

[waypoint-examples][master](4)$ waypoint context use 
Global Options:

  -workspace=<string>
      Workspace to operate in. Defaults to 'default'. The default is default.

Defaults to 'default'. The default is default. I can't tell if this is redundant, or possibly something telling me what the default normally is (default), and that possibly I've set a different default (but it's still default).

For example, possibly this could potentially say "The default is true, but you've set your default to false".
Or it's just doubled here by mistake. I tried looking through hashicorp/waypoint for where this lives, but I only found it in commands/index.mdx

go-glint error during install

Version: waypoint_0.0.1-beta2_darwin_amd64.zip

I reset things via the troubleshooting instructions.

$ docker pull docker.pkg.github.com/hashicorp/waypoint/alpha:latest
latest: Pulling from hashicorp/waypoint/alpha
Digest: sha256:1292129b22215ffa09dea2fd21086fbbd080b09f39370cecc42f5a01faf92a61
Status: Image is up to date for docker.pkg.github.com/hashicorp/waypoint/alpha:latest
docker.pkg.github.com/hashicorp/waypoint/alpha:latest

$ waypoint install -platform=docker
✓ Server container started
⠦ Retrieving initial auth token...panic: runtime error: slice bounds out of range [:36] with length 35

goroutine 1 [running]:
github.com/mitchellh/go-glint.clampTextWidth(0xc0001eca00, 0x24f, 0x4a, 0x24f, 0x0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/measure.go:179 +0x81f
github.com/mitchellh/go-glint.MeasureTextNode(0xc000775100, 0x42940000, 0x1, 0xc07fc00001, 0x0, 0x9)
        /go/pkg/mod/github.com/mitchellh/[email protected]/measure.go:76 +0x199
github.com/mitchellh/go-glint/flex.nodeWithMeasureFuncSetMeasuredDimensions(0xc000775100, 0x7fc0000142940000, 0x1, 0x0, 0x7fc0000142940000)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1276 +0x1af
github.com/mitchellh/go-glint/flex.nodelayoutImpl(0xc000775100, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0xffffffffffffff00, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1488 +0x5a2d
github.com/mitchellh/go-glint/flex.layoutNodeInternal(0xc000775100, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x0, 0x3ffb507, 0x7, 0x7d7b8e0, ...)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:2857 +0x587
github.com/mitchellh/go-glint/flex.nodeComputeFlexBasisForChild(0xc000774a00, 0xc000775100, 0x42940000, 0x1, 0x429400007fc00001, 0x7fc00001, 0x0, 0x1, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1070 +0x3fc
github.com/mitchellh/go-glint/flex.nodelayoutImpl(0xc000774a00, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x120fe00, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1645 +0xbea
github.com/mitchellh/go-glint/flex.layoutNodeInternal(0xc000774a00, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x0, 0x3ffb507, 0x7, 0x7d7b8e0, ...)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:2857 +0x587
github.com/mitchellh/go-glint/flex.nodeComputeFlexBasisForChild(0xc000774300, 0xc000774a00, 0x42940000, 0x1, 0x429400007fc00001, 0xc07fc00001, 0x0, 0x1, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1070 +0x3fc
github.com/mitchellh/go-glint/flex.nodelayoutImpl(0xc000774300, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x100cc00, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1645 +0xbea
github.com/mitchellh/go-glint/flex.layoutNodeInternal(0xc000774300, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x0, 0x3ffb507, 0x7, 0x7d7b8e0, ...)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:2857 +0x587
github.com/mitchellh/go-glint/flex.nodeComputeFlexBasisForChild(0xc000773c00, 0xc000774300, 0x42940000, 0x1, 0x429400007fc00001, 0x7fc00001, 0x0, 0x1, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1070 +0x3fc
github.com/mitchellh/go-glint/flex.nodelayoutImpl(0xc000773c00, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x0, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1645 +0xbea
github.com/mitchellh/go-glint/flex.layoutNodeInternal(0xc000773c00, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc0000142940000, 0x0, 0x3ffb507, 0x7, 0x7d7b8e0, ...)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:2857 +0x587
github.com/mitchellh/go-glint/flex.nodeComputeFlexBasisForChild(0xc000a71500, 0xc000773c00, 0x4294000042940000, 0x1, 0x429400007fc00001, 0xc07fc00001, 0x0, 0x1, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1070 +0x3fc
github.com/mitchellh/go-glint/flex.nodelayoutImpl(0xc000a71500, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc000017fc00001, 0x46f4101, 0x7d7b8e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:1645 +0xbea
github.com/mitchellh/go-glint/flex.layoutNodeInternal(0xc000a71500, 0x7fc0000142940000, 0x1, 0x1, 0x0, 0x7fc000017fc00001, 0x1, 0x3ffb1db, 0x7, 0x7d7b8e0, ...)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:2857 +0x587
github.com/mitchellh/go-glint/flex.CalculateLayout(0xc000a71500, 0x7fc000017fc00001, 0x1)
        /go/pkg/mod/github.com/mitchellh/[email protected]/flex/yoga.go:3040 +0x120
github.com/mitchellh/go-glint.(*Document).RenderFrame(0xc0000be280)
        /go/pkg/mod/github.com/mitchellh/[email protected]/document.go:178 +0x1f1
github.com/mitchellh/go-glint.(*Document).Close(0xc0000be280, 0xc000539a01, 0x8f0b830)
        /go/pkg/mod/github.com/mitchellh/[email protected]/document.go:95 +0x145
github.com/hashicorp/waypoint/sdk/terminal.(*glintUI).Close(0xc0001180d0, 0x47175c0, 0xc0001180d0)
        /home/circleci/project/waypoint/sdk/terminal/glint.go:31 +0x2e
github.com/hashicorp/waypoint/internal/cli.(*baseCommand).Close(0xc0004fe000, 0x0, 0xffffffffffffffff)
        /home/circleci/project/waypoint/internal/cli/base.go:96 +0x76
github.com/hashicorp/waypoint/internal/cli.(*InstallCommand).Run(0xc0001ca500, 0xc0000687a0, 0x1, 0x2, 0x0)
        /home/circleci/project/waypoint/internal/cli/install.go:419 +0xee2
github.com/mitchellh/cli.(*CLI).Run(0xc000846640, 0xc000846640, 0xc0009d8140, 0xc00029d340)
        /go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:262 +0x1da
github.com/hashicorp/waypoint/internal/cli.Main(0xc000068780, 0x3, 0x4, 0x0)
        /home/circleci/project/waypoint/internal/cli/main.go:97 +0x5ae
main.main()
        /home/circleci/project/waypoint/cmd/waypoint/main.go:14 +0xa2

Running it again show the server is already deployed:

$ waypoint install -platform=docker       
⚠️ Detected existing waypoint server
! Error getting the initial token: rpc error: code = PermissionDenied desc = server is alread
  
  The Waypoint server has been deployed, but due to this error we were
  unable to automatically configure the local CLI or the Waypoint server
  advertise address. You must do this manually using "waypoint context"
  and "waypoint server config-set".

"no deployments for service" after `waypoint up` in Ruby example

I'm following along the Ruby+Docker guide:

• https://waypointproject.io/docs/getting-started/docker-example-app

After running install, init and up successfully, I'm given 2 links:

           URL: https://lightly-dynamic-snake.alpha.waypoint.run
Deployment URL: https://lightly-dynamic-snake--01EJYF57W6TW3YWGTKZVB6XWFV.alpha.waypoint.run

The first URL works and points at my newly deployed Ruby app. The second url gives a 404 and says no deployments for service:

==> Releasing...

The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

           URL: https://lightly-dynamic-snake.alpha.waypoint.run
Deployment URL: https://lightly-dynamic-snake--01EJYF57W6TW3YWGTKZVB6XWFV.alpha.waypoint.run

[ruby][master](4)$ curl -I https://lightly-dynamic-snake.alpha.waypoint.run
HTTP/2 200
date: Wed, 23 Sep 2020 21:52:38 GMT
content-type: text/html; charset=utf-8
cache-control: max-age=0, private, must-revalidate
etag: W/"a82e48ebf0a8034eb38bd6a50709
[...]

[ruby][master](4)$ curl -i https://lightly-dynamic-snake--01EJYF57W6TW3YWGTKZVB6XWFV.alpha.waypoint.run
HTTP/2 404
date: Wed, 23 Sep 2020 21:52:58 GMT
content-type: text/plain; charset=utf-8
content-length: 27
x-content-type-options: nosniff

no deployments for service

Specify permissions needed for GH access token

In the README.md file, would be good to specify what the specific minimum access rights should be when a new user creates a GH personal access token for Waypoint. E.g. repo access, rw access for Packages, and workflow access for Actions.

Double scheme in URL output from kubernetes release plugin

Describe the bug
Using rc1 + some additional commits from main the output from waypoint release of the nodejs k8s example has a URL output with 2 schemes in it when using a sequence of individual deploy and release commands: https://http://localhost

$ waypoint deploy -release=false

» Deploying...

» Configuring https://kubernetes.docker.internal:6443 in namespace default
✓ Deployment successfully rolled out!

The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

           URL: https://widely-smiling-elephant.waypoint.run
Deployment URL: https://widely-smiling-elephant--v5.waypoint.run
$ waypoint release

» Releasing...

» Configuring https://kubernetes.docker.internal:6443 in namespace default
✓ Service successfully configured!

» Pruning old deployments...
  Deployment: 01EMEF3GJEX2JZN1W9AWHKY4WT

» Configuring https://kubernetes.docker.internal:6443 in namespace default

URL: https://http://localhost

Steps to Reproduce

1. Install waypoint-server in k8s
2. Deploy the node-js example from waypoint-examples
3. waypoint build
4. waypoint deploy -release=false
5. waypoint release

Expected behavior
The URL would have a single scheme like http://localhost

Support for docker config in docker-pull

I realize that the docker client in golang is closer to the metal than not, so this may be out of context.

But basically, it doesnt support credentials that exist in ~/.docker/config.json, which means that if I want to deploy artifacts that are built for me in a private repo, I now need to wrap waypoint with another tool (bash, make, whatever) that will get those credentials and let me feed them into the encoded_auth parameter in docker-pull.

Off the cuff brainstorming:

• some sort of mechanism for pre-checking that config.json when building a docker client
• a hook in docker-pull that lets me do a docker login using a helper

Exec plugin docs need to escape TPL

Describe the bug
The docs are not rendering "<TPL>" in html as intended.

Steps to Reproduce
See sentence "Any argument with the value "" in it will be replaced with the path to the template." in the exec plugin docs

This line seems responsible.

Expected behavior
"<TPL>" is rendered correctly in the website.

how to integrate the following additional configs

My workflow is as follows thru CI

1. build image
2. push to registry
3. generate manifest for k8s + istio service
4. push to git
5. git ops tool deploys to n clusters

how is the integration of the last 3 steps done in waypoint

As there is a concept of plugin/providers is there a provider for the above 3,4,5 points or basically an exec which is what the CI was doing anyway

Add command to stop server

Looks me as inconsistent CLI commands. I start server, no command to stop on localhost. You have to make docker ps && docker stop but will be nice to have command directly in waypoint server.

CLI for server command looks now:

Usage: waypoint server SUBCOMMAND

  Server management.

  The CLI, UI, and entrypoints all communicate to a Waypoint server. A
  Waypoint server is required for logs, exec, config, and more to work.
  The recommended way to run a server is "waypoint install".

  This command contains further subcommands to work with servers.

Subcommands:
    bootstrap     Bootstrap the server and retrieve the initial auth token
    config-set    Set the server online configuration.
    install       Install the Waypoint server to Kubernetes, Nomad, or Docker
    run           Manually run the builtin server

I will suggest small change to:

Usage: waypoint server SUBCOMMAND

  Server management.

  The CLI, UI, and entrypoints all communicate to a Waypoint server. A
  Waypoint server is required for logs, exec, config, and more to work.
  The recommended way to run a server is "waypoint install".

  This command contains further subcommands to work with servers.

Subcommands:
    bootstrap     Bootstrap the server and retrieve the initial auth token
    config-set    Set the server online configuration.
    install       Install the Waypoint server to Kubernetes, Nomad, or Docker
    start           Manually run the builtin server
    stop           Manually stop the builtin server

Describe alternatives you've considered

• alternative just name can be destroy and stay with run.

Explain any additional use-cases

• I think cli will be clear and UX will be better

InvalidParameterException trying to use an existing ECS cluster via the `cluster` parameter

Describe the bug
I have a static ECS cluster that was provisioned via Terraform along with the ECR repository for my container image. I then tried to use the waypoint.hcl file seen below and specify the name of the cluster via the cluster parameter. Based on this documentation, Waypoint should recognize the cluster already exists and skip trying to create it and just deploy to it.

Steps to Reproduce

1. Deploy the waypoint.hcl below with the ECS cluster, waypoint-nextjs-cluster, already created in your AWS account.

project = "example-next-ecs"

app "next-ecs" {
  build {
    use "pack" {}
    registry {
      use "aws-ecr" {
        region     = "us-west-2"
        repository = "nextjs-image"
        tag        = "latest"
      }
    }

  }

  # Deploy to ECS
  deploy {
    use "aws-ecs" {
      region  = "us-west-2"
      cluster = "waypoint-nextjs-cluster"
      memory  = "512"
    }
  }
}

With the existing cluster already provisioned, Waypoint throws the following error when you run up.

» Building...
Creating new buildpack-based image using builder: heroku/buildpacks:18
✓ Creating pack client
✓ Building image
 │ [exporter] Reusing layer 'config'
 │ [exporter] Adding label 'io.buildpacks.lifecycle.metadata'
 │ [exporter] Adding label 'io.buildpacks.build.metadata'
 │ [exporter] Adding label 'io.buildpacks.project.metadata'
 │ [exporter] *** Images (b3e6e24ef072):
 │ [exporter]       index.docker.io/library/next-ecs:latest
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:nodejs'
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:toolbox'
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:yarn'
 │ [exporter] Reusing cache layer 'heroku/nodejs-yarn:node_modules'
✓ Injecting entrypoint binary to image

Generated new Docker image: next-ecs:latest
Creating new buildpack-based image using builder: heroku/buildpacks:18✓ Creating pack client
✓ Building image
 │ [exporter] Reusing layer 'config'
 │ [exporter] Adding label 'io.buildpacks.lifecycle.metadata'
 │ [exporter] Adding label 'io.buildpacks.build.metadata'
 │ [exporter] Adding label 'io.buildpacks.project.metadata'
 │ [exporter] *** Images (b3e6e24ef072):
 │ [exporter]       index.docker.io/library/next-ecs:latest
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:nodejs'
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:toolbox'
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:yarn'
 │ [exporter] Reusing cache layer 'heroku/nodejs-yarn:node_modules'
✓ Injecting entrypoint binary to image

Generated new Docker image: next-ecs:latest
Tagging Docker image: next-ecs:latest => <aws-account-id>.dkr.ecr.us-west-2.amazonaws.com/nextjs-image:latest
Docker image pushed: <aws-account-id>.dkr.ecr.us-west-2.amazonaws.com/nextjs-image:latest

» Deploying...
❌ Creating new ECS cluster: waypoint-nextjs-cluster
! InvalidParameterException: Arguments on this idempotent request are inconsistent
  with arguments used in previous request(s).

Expected behavior
Waypoint should not try to create the ECS cluster and instead use the one that is already there by name.

Could not create any of the following paths: /home/waypoint/.config/waypoint

Describe the bug
When running waypoint install --platform=docker -accept-tos I see the following output in the docker container before it dies.

2020-10-15T22:42:39.286Z [INFO] waypoint: waypoint version: full_string="Waypoint v0.1.1 (44e2d3d6+CHANGES)" version=v0.1.1 prerelease= metadata= revision=44e2d3d6+CHANGES

2020-10-15T22:42:39.287Z [TRACE] waypoint: starting interrupt listener for context cancellation

! could not create any of the following paths: /home/waypoint/.config/waypoint,

/etc/xdg/waypoint

2020-10-15T22:42:39.291Z [TRACE] waypoint: stopping signal listeners and cancelling the context

Steps to Reproduce

1. Run waypoint install --platform=docker -accept-tos in a terminal instance on MacOS 10.15.7

Expected behavior
The docs indicate that I should see

✓ Server container started
Waypoint server successfully installed and configured!

The CLI has been configured to connect to the server automatically. This
connection information is saved in the CLI context named "install-1601411904".
Use the "waypoint context" CLI to manage CLI contexts.

The server has been configured to advertise the following address for
entrypoint communications. This must be a reachable address for all your
deployments. If this is incorrect, manually set it using the CLI command
"waypoint server config-set".

Advertise Address: waypoint-server:9701
HTTP UI Address: localhost:9702

Additional context
I'm using MacOS 10.15.7

Error when installing waypoint server to docker a second time

I successfully installed the server to docker once using $ waypoint install -platform=docker, but for whatever reason(s) I ended up removing it. The second time I tried, after stopping the container and removing the container, I got an error:

[waypoint-examples][master](4)$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

[waypoint-examples][master](4)$ docker pull docker.pkg.github.com/hashicorp/waypoint/alpha:latest
latest: Pulling from hashicorp/waypoint/alpha
Digest: sha256:08061add0a5bba65000586169ad5087e4b8d72b74f7f8d114171750252e6302a
Status: Image is up to date for docker.pkg.github.com/hashicorp/waypoint/alpha:latest
docker.pkg.github.com/hashicorp/waypoint/alpha:latest

[waypoint-examples][master](4)$ waypoint install -platform=docker
✓ Server container started
Error getting the initial token: rpc error: code = PermissionDenied desc = server is already bootstrapped

The Waypoint server has been deployed, but due to this error we were
unable to automatically configure the local CLI or the Waypoint server
advertise address. You must do this manually using "waypoint context"
and "waypoint server config-set".

@nicholasjackson suggested I may have a context in place (or not have one in place?) and asked that I check $HOME/.config/waypoint/context, but I don't have anything there:

[waypoint-examples][master](4)$ stat ~/.config/waypoint
stat: /Users/clint/.config/waypoint: stat: No such file or directory

Bug: panic in the config command

Describe the bug
The whole config sub-command panics. And even waypoint config doesn't work

Steps to Reproduce

waypoint config set PORT='8080'

Expected behavior
I expect to set the specified environment variable to my current app

Additional context
Log ouput:

➜ ✗  waypoint config                
panic: flag redefined: app

goroutine 1 [running]:
flag.(*FlagSet).Var(0xc000348120, 0x3ad3f60, 0xc0008a0520, 0x341eea2, 0x3, 0x34900c8, 0x26)
	/usr/local/go/src/flag/flag.go:851 +0x4b8
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).Var(0xc000352340, 0x3ad3f60, 0xc0008a0520, 0x341eea2, 0x3, 0x34900c8, 0x26)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:79 +0x6f
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).VarFlag(0xc000352340, 0xc0005a0b80)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:72 +0x1e1
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).StringVar(0xc000352340, 0xc0005a0a00)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_string.go:33 +0x212
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags.func1(0xc000782600)
	/home/circleci/project/waypoint/internal/cli/config_get.go:144 +0x18a
github.com/hashicorp/waypoint/internal/cli.(*baseCommand).flagSet(0xc000ac4000, 0x0, 0xc00085db40, 0x41324b)
	/home/circleci/project/waypoint/internal/cli/base.go:415 +0x224
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags(0xc0008a0400, 0xc00085db98)
	/home/circleci/project/waypoint/internal/cli/config_get.go:130 +0x5a
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Help(0xc0008a0400, 0xc0007825d0, 0x34314fa)
	/home/circleci/project/waypoint/internal/cli/config_get.go:171 +0x2f
github.com/mitchellh/cli.(*CLI).commandHelp(0xc000ac4140, 0x3ab07c0, 0xc00000e020, 0x3b052e0, 0xc000385a00)
	/go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:575 +0x894
github.com/mitchellh/cli.(*CLI).Run(0xc000ac4140, 0xc000ac4140, 0xc000384060, 0xc0007082a0)
	/go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:265 +0x227
github.com/hashicorp/waypoint/internal/cli.Main(0xc00024f300, 0x2, 0x2, 0x0)
	/home/circleci/project/waypoint/internal/cli/main.go:97 +0x4ee
main.main()
	/home/circleci/project/waypoint/cmd/waypoint/main.go:14 +0xa2

Open documentation

It looks like the documentation repository for waypoint is not opened yet.

I get 404 errors when clicking "edit this page" here:
https://www.waypointproject.io/docs/extending-waypoint/creating-plugins/testing

the link points to https://github.com/hashicorp/blue/blob/master/website/content/docs/extending-waypoint/creating-plugins/testing.mdx which is a 404 to me.

Build failure: go-bindata: command not found

Describe the bug
I am getting the following error on a fresh build after cloning the repo:

$ make bin
GOOS=linux GOARCH=amd64 go build -o ./internal/assets/ceb/ceb ./cmd/waypoint-entrypoint
cd internal/assets && go-bindata -pkg assets -o prod.go -tags assetsembedded ./ceb
/bin/sh: go-bindata: command not found
make: *** [Makefile:15: bin] Error 127

Steps to Reproduce
Steps to reproduce the behavior. Please include any waypoint.hcl files
if applicable.

• Clone repo

$ git clone https://github.com/hashicorp/waypoint.git
Cloning into 'waypoint'...
remote: Enumerating objects: 185, done.
remote: Counting objects: 100% (185/185), done.
remote: Compressing objects: 100% (131/131), done.
remote: Total 19662 (delta 79), reused 95 (delta 47), pack-reused 19477
Receiving objects: 100% (19662/19662), 25.85 MiB | 14.79 MiB/s, done.
Resolving deltas: 100% (13314/13314), done.

• cd into repo dir
• Run make bin

$ make bin
GOOS=linux GOARCH=amd64 go build -o ./internal/assets/ceb/ceb ./cmd/waypoint-entrypoint
cd internal/assets && go-bindata -pkg assets -o prod.go -tags assetsembedded ./ceb
/bin/sh: go-bindata: command not found
make: *** [Makefile:15: bin] Error 127

Expected behavior
A clear and concise description of what you expected to happen.

Successful build expected.

Additional context
Add any other context about the problem here.

None.

Pre-deploy actions

I would like to perform actions before deploy section (create kubernetes namespace)

Many option i use it in yaml to create deployment is missing(not yet released) in my case specify the namespace to deploy to.

Waypoint Helm Chart

Being able to deploy the Waypoint Server in a K8s cluster that exposes everything needed in a simple manner is needed. Then, our Gitlab CI/CD process can communicate with Waypoint without running the server in that process.

Kubernetes destroy does not remove the associated k8s service

Describe the bug
waypoint destroy leaves behind a k8s service resource for the app.

Steps to Reproduce

1. install waypoint in k8s
2. use waypoint-examples kubernetes nodejs app with waypoint up
3. waypoint destroy
4. Confirm that the associated k8s service service/example-nodejs still exists

$ kubectl get service/example-nodejs
NAME             TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
example-nodejs   LoadBalancer   10.107.32.18   localhost     80:32345/TCP   6m1s

Expected behavior
service/example-nodejs is deleted.

Kaniko Plugin Support

We use Gitlab CI/CD and have moved away from using Docker in Docker. Kaniko is a safer way to build images and would like support for that in Waypoint

UI: app page has broken release button

I'm at the UI step of the walkthrough. I've deployed (waypoint up) an app but that's it.

At this point there's a few broken buttons. They just link to the current url with target="_blank". Instead of a name there's just an empty <span>.

From Jack:

Yeah. The link is just empty. It should throw an error instead of rendering it like that at the least, but I’d guess you don’t yet have a URL populated on your latest release

Screenshot

The missing text issue is in the top and bottom blue buttons on the right. All three buttons are missing their url.

Packer builder plugin

Packer supports multiple output formats and it would be great to be able to use it inside waypoint. Currently, it would be able to integrate with aws-ec2 deploy plugin.

Possible config:

build {
  use "packer" {
    template = "./build.pkr.hcl"
    var_file = "./variables.json"
    var = {
      region = "us-east-1"
    }
    except = ...
    ...
  }
}

waypoint should be able to inject manifest post-processor and grab required artefact ids from its output.

Deploy an Example App with Docker: Add step to examine logs and cleanup

In the Deploy an Example App with Docker documentation, prior to Walkthrough Summary, could we add a step to examine the logs:

waypoint logs

Could we also add a step to clean up?

waypoint destroy

K8s: waypoint installer connecting to service too early

Describe the bug
Installation on some flavors of Kubernetes can be inconsistent due to timeout errors. I believe this is happening because Waypoint inspects the Kubernetes Load Balancer for an external IP address and tries to use it as soon as it's available. The pod, however, is not yet running so nothing is being routed to the pod and it eventually causes a timeout error:

! Error connecting to server: context deadline exceeded

When deploying to K8s it might be more efficient to inspect if the Statefulset is ready before attempting to use the service. This should make the installation more reliable.

Steps to Reproduce

On an EKS cluster, I can run the following pretty consistently to reproduce the issue:

waypoint install -platform=kubernetes -namespace=waypoint -accept-tos

Expected behavior

Installation of the Waypoint server should succeed because the pod and service both eventually run without issue.

Additional context

It can take a while for the pod to come online for various reasons: persistent storage creation, docker image pull, scheduling bottlenecks, etc.

CLI: `deployment destroy` takes different arg than `deployment list` prints

$ wp deployment list
     | ID | PLATFORM |    DETAILS    |  STARTED   | COMPLETED   
-----+----+----------+---------------+------------+-------------
  🚀 |  3 | docker   | image:e080e28 | 1 hour ago | 1 hour ago  
     |    |          | language:ruby  
  ✔  |  2 | docker   | image:1761be7 | 1 hour ago | 1 hour ago  
     |    |          | language:ruby

$ wp deployment destroy 2
record not found for ID: 2

$ wp deployment destroy 01EJHFH87V73BM04TT5AFMAQ6E 

==> 1 deployments will be destroyed.
    Destroying deployment: 01EJHFH87V73BM04TT5AFMAQ6E

$ wp deployment list -long-ids      
     |               ID               | PLATFORM |    DETAILS    |  STARTED   | COMPLETED   
-----+--------------------------------+----------+---------------+------------+-------------
  🚀 | 3 (01EJHFN5QQ4FSQ238MDXG5M2R2) | docker   | image:e080e28 | 1 hour ago | 1 hour ago  
     |                                |          | language:ruby  

the sequential ids given by default are not usable for the sibling command deployment destroy <id>. wp deployment list -long-ids works but it's awkward to discover. would be nice if the long ids were shown by default, or if destroy accepted both ids.

internal/pkg/epinject: fails if `/bin` doesn't exist

Describe the bug
If the Docker image being built does not have a /bin directory, then the epinject package can fail.

Steps to Reproduce
Just modify the builtin/docker/builder.go epinject call to use say /binfoo (a path that doesn't normally exist) and it'll fail.

Expected behavior
Should probably create the directory, or we can use root.

K8s plugin: apps deployed to different namespaces can't connect Waypoint server

Describe the bug
Applications deployed to a namespace that does not have the Waypoint server cannot connect to the Waypoint server. The result is a gRPC connection error:

2020-10-15T17:50:13.588Z [TRACE] starting interrupt listener for context cancellation
2020-10-15T17:50:13.589Z [INFO]  entrypoint starting: deployment_id=01EMPP4ATB840XEX2VNS89E6D9 instance_id=01EMPP4EJN61FTH40CKX970MEE args=[/app]
2020-10-15T17:50:13.589Z [INFO]  connecting to server: addr=35.223.164.111:9701 tls=true tls_skip_verify=true
2020-10-15T17:50:13.589Z [TRACE] interrupt listener goroutine started
2020-10-15T17:50:13.616Z [TRACE] server connection successful
2020-10-15T17:50:13.616Z [INFO]  converting invite token to login token
Error initializing Waypoint entrypoint: failed to connect to server: rpc error: code = InvalidArgument desc = required header client-api-protocol is not set
2020-10-15T17:50:13.618Z [TRACE] stopping signal listeners and cancelling the context

The Kubernetes plugin doesn't explicitly support deploying an application to a specific namespace, but since Waypoint CLI is using my local kubeconfig, I can force it by doing: kubectl config set-context --current --namespace=myapp

Steps to Reproduce

$ kubectl create namespace waypoint
$ waypoint install -platform=kubernetes \
    -namespace=waypoint \
    -accept-tos \
    -server-image=hashicorp/waypoint:latest
$ kubectl create namespace app
$ kubectl config set-context --current --namespace=app
$ waypoint init && waypoint up

Expected behavior

The entrypoint in the deployed app should be able to connect to the Waypoint server running in a different namespace.

install/k8s: kind requires LoadBalancer

This guide shows that if we have minimal kind cluster then we can install waypoint but we still need LoadBalancer requirement
and we should use metallb or something like that: https://learn.hashicorp.com/tutorials/waypoint/get-started-kubernetes?in=waypoint/get-started-kubernetes

Steps to Reproduce
Following the guide doesn't end you up in a working state.

Expected behavior
Example should be complete with LoadBalancer installation or configuring waypoint to use NodePort.

Error on waypoint install for Docker

Describe the bug
Following the getting started guide, the waypoint install --platform=docker -accept-tos command fails with this output:

! Error installing server into docker: Error response from daemon: No such image: hashicorp/waypoint:latest

Steps to Reproduce

Follow the instructions on https://www.waypointproject.io/docs/getting-started (I am running ElementaryOS Hera, which is based on Ubuntu Bionic) up to and including the install command.

Expected behavior

I expected the install to complete successfully.

Additional context

A docker pull hashicorp/waypoint:latest completes successfully.

! Error initializing server: context deadline exceeded

Describe the bug
Waypoint for docker is crashing with this error

Steps to Reproduce
Steps to reproduce the behavior. Please include any waypoint.hcl files
if applicable.

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

020-10-15T21:17:13.037Z [INFO] waypoint: waypoint version: full_string="Waypoint v0.1.1 (44e2d3d6+CHANGES)" version=v0.1.1 prerelease= metadata= revision=44e2d3d6+CHANGES

2020-10-15T21:17:13.037Z [TRACE] waypoint: starting interrupt listener for context cancellation

2020-10-15T21:17:13.038Z [TRACE] waypoint: interrupt listener goroutine started

2020-10-15T21:17:13.038Z [DEBUG] waypoint: home configuration directory: path=/home/waypoint/.config/waypoint

2020-10-15T21:17:13.038Z [INFO] waypoint.server: opening DB: path=/data/data.db

2020-10-15T21:17:23.009Z [INFO] waypoint.server: gracefully closing db: path=/data/data.db

2020-10-15T21:17:23.009Z [TRACE] waypoint: stopping signal listeners and cancelling the context

! Error initializing server: context deadline exceeded

Admin UI does not fit on iPad/tablet width

When viewing the Waypoint UI at iPad/tablet width, some contents require side to side scrolling (builds, deployments, releases) while others fit (menu, logs).

Given that iPad dimensions are used for many screenshots across all HashiCorp products, the UI should be designed to fit within iPad screen dimensions.

Steps to reproduce:

• Load the Waypoint UI in Google Chrome
• Press Command-Alt-I to load the developer console
• Press Command-Shift-M or click the mobile/tablet icon to load the device toolbar
• Select "iPad" and click the orientation button to select horizontal orientation

windows builds fail

Our Windows builds are failing so Waypoint 0.1 doesn't support Windows.

We'll fix these and quickly release a 0.1.1:

# github.com/mitchellh/go-glint
../../../../pkg/mod/github.com/mitchellh/[email protected]/renderer_term.go:40:15: undefined: pty.GetsizeFull
# github.com/hashicorp/waypoint/internal/server/ptypes
internal/server/ptypes/window_size.go:10:52: undefined: pty.Winsize
internal/server/ptypes/window_size.go:15:10: undefined: pty.Winsize
internal/server/ptypes/window_size.go:23:23: undefined: pty.Winsize

Nomad Plugin - allow specification of an hcl file

Waypoint looks really interesting but isn't quite flexible enough for us yet (definitely understand its a day 1 release). Of particular note for us is being able to get deployment feedback from Nomad (e.g., whether allocations of a job actually enter a running state).

One of the big items that would block adoption for us is being able to use existing Nomad job files, and I wouldn't necessarily expect (or want to wait for) abstraction of all nomad options. Instead, what about allowing users to specify a path to an hcl file to use?

That seems like it would lower overhead for feature requests while allowing lots of custom setups to work without too much modification.

Example of one of our local dev nomad jobs below:

job "edge-server" {

  datacenters = ["local"]
  type        = "service"
  
  group "edge-server" {

    count = 1

    update {
      max_parallel     = 1
      auto_revert      = "true"
      min_healthy_time = "30s"
      healthy_deadline = "2m"
    }

    # scratch space for all tasks in this group, must include space
    # for all the logs (100 MB by default)
    ephemeral_disk {
      size = 200 # MB
    }

    task "edge-server" {

      driver = "docker"

      config {
        image        = "density/edge-server:0"
        network_mode = "host"

        logging {
          type = "fluentd"
          config {
            fluentd-async-connect = true
            fluentd-address       = "${attr.unique.network.ip-address}:24224"
            tag                   = "edge-server"
          }
        }
      }

      # cgroup-limited resources for the container on the host
      resources {
        cpu    = 256
        memory = 512
        network {
          port "http" {
            static = 80
          }
          port "metrics" {
            static = 8888
          }
        }
      }

      service {
        name = "edge-server"
        port = "http"
        
        check {
          type     = "http"
          port     = "http"
          path     = "/health"
          interval = "10s"
          timeout  = "2s"
        }

        check {
          type     = "script"
          name     = "check_config"
          command  = "/bin/nginx"
          args     = ["-T"]
          interval = "60s"
          timeout  = "5s"
        }
      }

    }
  }
}

Output full URLs in CLI post-install message

Is your feature request related to a problem? Please describe.
After running waypoint install, the HTTP UI address is shown on the console. It's the tiniest thing, but it would be nice if I could use my terminal's URL recognition capabilities to just navigate to it easily in my browser.

Describe the solution you'd like
Instead of

HTTP UI Address: localhost:9702

could it instead output

HTTP UI Address: https://localhost:9702/

?

GCP: "waypoint build" fails, "Error parsing reference... invalid reference format"

Describe the bug

waypoint build fails with error:

Generated new Docker image: example-nodejs:latest
❌ Tagging Docker image: example-nodejs:latest =>
gcr.io/<my-project-name>/example-nodejs:latest
! unable to tag image:Error parsing reference:
  "gcr.io/<my-project-name>/example-nodejs:latest" is not a valid repository/tag:
  invalid reference format

Steps to Reproduce

1. cd waypoint-examples/google-cloud-run/nodejs
2. waypoint build

Expected behavior

Expected app to build, and push a Docker image to GCR.

Additional context

From the error I'd have expected a manual tag to fail. However, tagging and pushing manually succeeds:

docker  tag example-nodejs:latest gcr.io/site-randocat/example-nodejs:latest
docker push gcr.io/site-randocat/example-nodejs:latest

The "push" correctly pushes an image to GCR.

Gcloud correctly knows my default project name, as verified by "gcloud config list --format 'value(core.project)'"

waypoint config crashes

I installed waypoint via the Fedora repository.

The commande waypoint config crashes:

$ waypoint config
panic: flag redefined: app

goroutine 1 [running]:
flag.(*FlagSet).Var(0xc0001584e0, 0x3ad3f60, 0xc000dac0e0, 0x341eea2, 0x3, 0x34900c8, 0x26)
        /usr/local/go/src/flag/flag.go:851 +0x4b8
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).Var(0xc000154700, 0x3ad3f60, 0xc000dac0e0, 0x341eea2, 0x3, 0x34900c8, 0x26)
        /home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:79 +0x6f
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).VarFlag(0xc000154700, 0xc000bbaa00)
        /home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:72 +0x1e1
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).StringVar(0xc000154700, 0xc000bba900)
        /home/circleci/project/waypoint/internal/pkg/flag/flag_string.go:33 +0x212
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags.func1(0xc000dce180)
        /home/circleci/project/waypoint/internal/cli/config_get.go:144 +0x18a
github.com/hashicorp/waypoint/internal/cli.(*baseCommand).flagSet(0xc00014a000, 0x0, 0xc000e9fb40, 0x41324b)
        /home/circleci/project/waypoint/internal/cli/base.go:415 +0x224
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags(0xc000d5dfc0, 0xc000e9fb98)
        /home/circleci/project/waypoint/internal/cli/config_get.go:130 +0x5a
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Help(0xc000d5dfc0, 0xc000dce150, 0x34314fa)
        /home/circleci/project/waypoint/internal/cli/config_get.go:171 +0x2f
github.com/mitchellh/cli.(*CLI).commandHelp(0xc00014a140, 0x3ab07c0, 0xc00000e020, 0x3b052e0, 0xc000d5d2e0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:575 +0x894
github.com/mitchellh/cli.(*CLI).Run(0xc00014a140, 0xc00014a140, 0xc000d5c000, 0xc000b822a0)
        /go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:265 +0x227
github.com/hashicorp/waypoint/internal/cli.Main(0xc000cda9e0, 0x2, 0x2, 0x0)
        /home/circleci/project/waypoint/internal/cli/main.go:97 +0x4ee
main.main()
        /home/circleci/project/waypoint/cmd/waypoint/main.go:14 +0xa2

Waypoint getting started on Docker doesn't work

Describe the bug
waypoint up deploys the example nodejs app, but the URL is not accessible.

Steps to Reproduce
Follow the steps in getting started section here to use waypoint with docker.

Expected behavior
The preview URL should display the static nodejs page.

Add fargate support

Describe the solution you'd like
I would like to have aws fargate support. Serverless containers make it even easier to deploy in a fast manner.

Wrapped `waypoint build` log output crashes vscode

Bug

Log output wraps poorly and eventually hangs vscode. Requires a UI reload to fix.

To Reproduce

• open a Terminal
• split the Terminal so there's 2
• run waypoint up

Workaround

Make the Terminal window wide enough to print without wrapping. Normal output works fine and does not hang or crash.

Screenshots

Feature: CI/CD Documentation

Waypoint seems like a great addition to the Hashicorp tool stack.

In my organization, no one is allowed to deploy to any server from a CLI. All deployments to any infrastructure should be through a CI/CD pipeline. It is how we do Terraform as well. While I love my developer teams, deployments via CLI is just asking for conflicts and management issues.

In that regard, I think it would be helpful for the Waypoint documentation to provide some CI/CD examples.
It would also be great for Hashicorp to demonstrate a full-stack example with all the products. A K8S cluster described in Terraform, Waypoint for deploying a multi-service (microservice ideally) application with service discovery and a public endpoint path via an API gateway, and security via Vault.

But, at minimum, tutorials for users to see a full CI/CD with testing, build, and deployment of an app. The NodeJS examples are great - I'd suggest adopting Typescript for NodeJS examples as that is the trend in enterprise development on that stack. And, of course, Python, Java, C#, and GoLang examples will help facilitate adoption.

Very supportive of this tool. On the application level, there is a lack of solid tooling with the "Deploy Anywhere" methodology in mind.

Panic caused by waypoint destroy

When attempting to clean up an app deployed to GKE, I get the following panic:

[~/Git/waypoint-examples/kubernetes/nodejs] waypoint destroy

==> Destroying releases...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x19fc226]

goroutine 84 [running]:
github.com/hashicorp/waypoint/sdk/internal/plugin.(*destroyerClient).Implements(0x0, 0x4735a00, 0xc0000c8008, 0x3d69a48, 0x3d69a38, 0xc000a294c0)
	/home/circleci/project/waypoint/sdk/internal/plugin/destroyer.go:28 +0x36
github.com/hashicorp/waypoint/sdk/internal/plugin.(*destroyerClient).DestroyFunc(0x0, 0x1, 0x8fb4240)
	/home/circleci/project/waypoint/sdk/internal/plugin/destroyer.go:37 +0x58
github.com/hashicorp/waypoint/internal/core.(*releaseDestroyOperation).Do(0xc0005341d0, 0x47359c0, 0xc0007c9dc0, 0x47778e0, 0xc0007697a0, 0xc000659420, 0x4711f40, 0xc00055aa50, 0xc00055aa50, 0x0, ...)
	/home/circleci/project/waypoint/internal/core/app_release_destroy.go:150 +0x21e
github.com/hashicorp/waypoint/internal/core.(*App).doOperation(0xc000659420, 0x47359c0, 0xc0007c9dc0, 0x47778e0, 0xc0007697a0, 0x4753320, 0xc0005341d0, 0x0, 0x0, 0x0, ...)
	/home/circleci/project/waypoint/internal/core/operation.go:125 +0x10bd
github.com/hashicorp/waypoint/internal/core.(*App).DestroyRelease(0xc000659420, 0x47359c0, 0xc0007c9dc0, 0xc00055a2c0, 0x1, 0x1)
	/home/circleci/project/waypoint/internal/core/app_release_destroy.go:30 +0x1e4
github.com/hashicorp/waypoint/internal/core.(*App).destroyAllReleases(0xc000659420, 0x47359c0, 0xc0007c9dc0, 0x83, 0x16f)
	/home/circleci/project/waypoint/internal/core/app_release_destroy.go:54 +0x1be
github.com/hashicorp/waypoint/internal/core.(*App).Destroy(0xc000659420, 0x47359c0, 0xc0007c9dc0, 0xe, 0xc000540638)
	/home/circleci/project/waypoint/internal/core/app_destroy.go:30 +0x166
github.com/hashicorp/waypoint/internal/runner.(*Runner).executeDestroyOp(0xc0001dc3c0, 0x47359c0, 0xc0007c9dc0, 0xc000c2a820, 0xc000a69110, 0x2, 0x10, 0x0)
	/home/circleci/project/waypoint/internal/runner/operation_destroy.go:33 +0x1f6
github.com/hashicorp/waypoint/internal/runner.(*Runner).executeJob(0xc0001dc3c0, 0x47359c0, 0xc0007c9dc0, 0x47778e0, 0xc000776000, 0x47592c0, 0xc0009183a0, 0xc000c2a820, 0x0, 0x0, ...)
	/home/circleci/project/waypoint/internal/runner/operation.go:104 +0xa54
github.com/hashicorp/waypoint/internal/runner.(*Runner).accept(0xc0001dc3c0, 0x47359c0, 0xc0007c9dc0, 0xc000adf220, 0x1a, 0x0, 0x0)
	/home/circleci/project/waypoint/internal/runner/accept.go:210 +0x13ba
github.com/hashicorp/waypoint/internal/runner.(*Runner).AcceptExact(...)
	/home/circleci/project/waypoint/internal/runner/accept.go:35
github.com/hashicorp/waypoint/internal/client.(*Project).doJob.func1.1(0xc0001dc3c0, 0x47359c0, 0xc0007c9940, 0xc000adf220, 0x1a, 0x47778e0, 0xc0009808c0)
	/home/circleci/project/waypoint/internal/client/job.go:79 +0x57
created by github.com/hashicorp/waypoint/internal/client.(*Project).doJob.func1
	/home/circleci/project/waypoint/internal/client/job.go:78 +0x76

Here is the waypoint.hcl I'm using:

project = "example-nodejs"

app "example-nodejs" {
  labels = {
    "service" = "example-nodejs",
    "env" = "dev"
  }

  build {
    use "pack" {}
    registry {
        use "docker" {
          image = "gcr.io/vault-helm-dev/hashicorp/nodejs-example"
          tag = "latest"
        }
    }
 }

  deploy {
    use "kubernetes" {
    probe_path = "/"
    }
  }

  release {
    use "kubernetes" {
      load_balancer = true
      port = 80
    }
  }
}

entrypoint: URL service TLS errors on minimal Docker images

Describe the bug
For minimal Docker image (i.e. from scratch) that do not have the public CA cert bundles, our injected entrypoint can't validate TLS for the connection to our default URL service.

Steps to Reproduce
The example here will do it: #381

Expected behavior
Entrypoint works, probably, because I think a lot of Docker images will be this way.

Additional context
One idea here is to embed the CA cert chain that we'll use with the default URL service cluster and ONLY use that if the certs aren't in the cert chain already?

Confirm waypoint destroy

waypoint destroy worked great and was very quick. It was over before I had the chance to think to myself what the consequences were. I would like to contribute a confirmation step if others agree it would be useful, similar to terraform destroy.

Couldn't find a Waypoint deployment with this URL

Describe the bug
After running the following command waypoint up could see in the console output

Deployment URL: https://globally-helping-haddock--v4.waypoint.run

but, when opening the url in a browser tab getting the error Couldn't find a Waypoint deployment with this URL

Also, please find attache the snapshot of the error.

Steps to Reproduce
Follow the exact steps mentioned in the Getting Started guide https://www.waypointproject.io/docs/getting-started
After running the command waypoint up i could see the below response on the console.

» Building...
Creating new buildpack-based image using builder: heroku/buildpacks:18
 + Creating pack client
 + Building image
 │ [exporter] Adding 1/1 app layer(s)
 │ [exporter] Adding layer 'launcher'
 │ [exporter] Adding layer 'config'
 │ [exporter] Adding label 'io.buildpacks.lifecycle.metadata'
 │ [exporter] Adding label 'io.buildpacks.build.metadata'
 │ [exporter] Adding label 'io.buildpacks.project.metadata'
 │ [exporter] *** Images (ebe25a8c6faa):
 │ [exporter]       index.docker.io/library/example-nodejs:latest
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:nodejs'
 │ [exporter] Reusing cache layer 'heroku/nodejs-engine:toolbox'
 + Injecting entrypoint binary to image

Generated new Docker image: example-nodejs:latest

» Deploying...
 + Setting up waypoint network
 + Starting container
 + App deployed as container: example-nodejs-01EMR1KCKSCCEZBFY72S2F9MA8

» Releasing...

» Pruning old deployments...
  Deployment: 01EMQXFT1WH5C1NC6TDG17KHPH

The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

           URL: https://globally-helping-haddock.waypoint.run
Deployment URL: https://globally-helping-haddock--v4.waypoint.run

Expected behavior
Should be able to see the url with demo content

Additional context

Docker nomad driver volumes and network_mode

I currently run several nomad services that talk to each other. They both run with network_mode=host, and share a volume.

I'm playing around with getting these deployed via waypoint, but I'm not seeing any way to do this yet. Is it possible and I'm just missing it, or is it just early days? (which is obviously totally cool)

Waypoint not working on existing kubernetes cluster

following the documentation I installed waypoint and have kubeconfig in place
Going through the nodejs repo I change docker section to push the image to my repo else it would be errimagepull

waypoint.hcl looks like this

project = "example-nodejs"

app "example-nodejs" {
  labels = {
      "service" = "example-nodejs",
      "env" = "dev"
  }

  build {
    use "pack" {}
    registry {
        use "docker" {
          image = "saiyam911/example-nodejs"
          tag = "1"
          
        }
    }
 }

  deploy { 
    use "kubernetes" {
     
    }
  }

  release {
    use "kubernetes" {
      node_port = 31766
    }
  }
}

The pod goes into running but the liveliness and readiness probe fails
If I manually go and remove the readiness and liveliness probe the pod runs but the service is not accessible

Is there something I am missing or doing wrong ?

ARM support for docker image

Would be great to have official docker images for ARMHF etc

Unable to run create-react-app in Kubernetes with Waypoint

Description
When I use waypoint to deploy a reactjs based application created using create-react-app (or an AngularJS app for that matter) using Kubernetes as the deployment point - the deployment goes into a Running state for a few moments, then into Completed, then into CrashLoopBackOff. This happens with multiple customer written applications, as well as the "baseline" project deployed. This same behavior is experienced with the Nomad integration as well.

Briefly discussed this issue with @pearkes and @nicholasjackson - opening issue here to track.

Steps to reproduce

1. Clone test repository for simple react app
   git clone https://github.com/codyde/wp-react

2. Create the waypoint config file

project = "my-project"

app "wp-react" {
  labels = {
    "service" = "wp-react",
    "env"     = "dev"
  }

  build {
    use "pack" {}
    registry {
      use "docker" {
        image = "waypoint-example.local/wp-react"
        tag   = "latest"
      }
    }
  }

  deploy {
    use "kubernetes" {
      probe_path = "/"
    }
  }

  release {
    use "kubernetes" {
      load_balancer = true
      port          = 8080
    }
  }
}

3. Waypoint install/init/up

4. Observe pod in crashloop

---

What have I tested against?
Docker for Desktop based Kubernetes 1.16 cluster, vSphere based Kubernetes 1.17 cluster, Amazon EKS cluster

What have I tried?
Building the docker container normally works fine when running in both Docker and Kubernetes. The waypoint build works when running against the docker deployment but when using Kubernetes the deployment fails.

Log Files

❯ k logs wp-react-01egqakev4k5avbw19pecx08fx-ddc669497-xssxz
2020-08-27T06:45:38.539Z [TRACE] starting interrupt listener for context cancellation
2020-08-27T06:45:38.540Z [INFO]  entrypoint starting: deployment_id=01EGQAKDZQHMQDTN8YYE2M404Q instance_id=01EGQAMB3CS6EK039X9ESS27AR args=[/cnb/lifecycle/launcher]
2020-08-27T06:45:38.540Z [INFO]  connecting to server: addr=192.168.1.78:9701 tls=true tls_skip_verify=true
2020-08-27T06:45:38.542Z [TRACE] interrupt listener goroutine started
2020-08-27T06:45:38.578Z [TRACE] server connection successful
2020-08-27T06:45:38.579Z [INFO]  converting invite token to login token
2020-08-27T06:45:38.583Z [INFO]  reconnecting to server with authentication
2020-08-27T06:45:38.638Z [DEBUG] config: registering instance, requesting config
2020-08-27T06:45:38.639Z [TRACE] config: config stream connected, waiting for first config
2020-08-27T06:45:38.640Z [TRACE] config: first config received
2020-08-27T06:45:38.640Z [INFO]  url: url service enabled, configuring: addr=https://control.alpha.hzn.network service_port=3000 labels=waypoint/workspace=default,env=dev,service=wp-react,waypoint.hashicorp.com/app=wp-react,waypoint.hashicorp.com/project=my-project,waypoint.hashicorp.com/workspace=default,:deployment=01egqakdzqhmqdtn8yye2m404q
2020-08-27T06:45:38.640Z [DEBUG] url: discovering hubs
2020-08-27T06:45:38.641Z [DEBUG] url: refreshing data
2020-08-27T06:45:38.851Z [DEBUG] url.agent: connecting to hub: addr=54.191.228.67:443
2020-08-27T06:45:38.856Z [DEBUG] url.agent: connecting to hub: addr=52.32.248.197:443
2020-08-27T06:45:39.126Z [DEBUG] url.agent: connection latency: latency=93.532029ms
2020-08-27T06:45:39.126Z [DEBUG] url.agent: connected successfully: status=connected latency=93.532029ms skew=19.788185ms
2020-08-27T06:45:39.149Z [DEBUG] url.agent: connection latency: latency=116.70178ms
2020-08-27T06:45:39.149Z [DEBUG] url.agent: connected successfully: status=connected latency=116.70178ms skew=20.891864ms
2020-08-27T06:45:43.769Z [DEBUG] url.agent: connected to hub: addr=54.191.228.67:443
2020-08-27T06:45:43.769Z [DEBUG] url.agent: connected to hub: addr=52.32.248.197:443
2020-08-27T06:45:43.769Z [DEBUG] log: connecting to log stream
2020-08-27T06:45:43.770Z [TRACE] log: log stream connected
2020-08-27T06:45:43.770Z [INFO]  starting child process: args=[/cnb/lifecycle/launcher] cmd=/cnb/lifecycle/launcher

> [email protected] start /workspace
> react-scripts start

2020-08-27T06:45:44.280Z [TRACE] log: sending line: line=
2020-08-27T06:45:44.280Z [TRACE] log: sending line: line="> [email protected] start /workspace"
2020-08-27T06:45:44.281Z [TRACE] log: sending line: line="> react-scripts start"
2020-08-27T06:45:44.281Z [TRACE] log: sending line: line=
ℹ ｢wds｣: Project is running at http://172.18.72.65/
2020-08-27T06:45:47.294Z [TRACE] log: sending line: line="ℹ ｢wds｣: Project is running at http://172.18.72.65/"
ℹ ｢wds｣: webpack output is served from
2020-08-27T06:45:47.295Z [TRACE] log: sending line: line="ℹ ｢wds｣: webpack output is served from "
ℹ ｢wds｣: Content not from webpack is served from /workspace/public
ℹ ｢wds｣: 404s will fallback to /
Starting the development server...

2020-08-27T06:45:47.296Z [TRACE] log: sending line: line="ℹ ｢wds｣: Content not from webpack is served from /workspace/public"
2020-08-27T06:45:47.296Z [TRACE] log: sending line: line="ℹ ｢wds｣: 404s will fallback to /"
2020-08-27T06:45:47.296Z [TRACE] log: sending line: line="Starting the development server..."
2020-08-27T06:45:47.296Z [TRACE] log: sending line: line=
2020-08-27T06:45:47.338Z [INFO]  subprocess gracefully exited: args=[/cnb/lifecycle/launcher] cmd=/cnb/lifecycle/launcher
2020-08-27T06:45:47.339Z [TRACE] stopping signal listeners and cancelling the context

waypoint config panics

Describe the bug

$ waypoint config
panic: flag redefined: app

goroutine 1 [running]:
flag.(*FlagSet).Var(0xc0003f24e0, 0x46c7740, 0xc000b56160, 0x40138cc, 0x3, 0x4084216, 0x26)
	/usr/local/go/src/flag/flag.go:851 +0x4b8
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).Var(0xc0003ea700, 0x46c7740, 0xc000b56160, 0x40138cc, 0x3, 0x4084216, 0x26)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:79 +0x6f
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).VarFlag(0xc0003ea700, 0xc000acaf00)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_var.go:72 +0x1e1
github.com/hashicorp/waypoint/internal/pkg/flag.(*Set).StringVar(0xc0003ea700, 0xc000acae00)
	/home/circleci/project/waypoint/internal/pkg/flag/flag_string.go:33 +0x212
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags.func1(0xc000b76180)
	/home/circleci/project/waypoint/internal/cli/config_get.go:144 +0x18a
github.com/hashicorp/waypoint/internal/cli.(*baseCommand).flagSet(0xc0003dc000, 0x0, 0xc000c1fb40, 0x101309b)
	/home/circleci/project/waypoint/internal/cli/base.go:415 +0x224
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Flags(0xc000b56080, 0xc000c1fb98)
	/home/circleci/project/waypoint/internal/cli/config_get.go:130 +0x5a
github.com/hashicorp/waypoint/internal/cli.(*ConfigGetCommand).Help(0xc000b56080, 0xc000b76150, 0x4025d07)
	/home/circleci/project/waypoint/internal/cli/config_get.go:171 +0x2f
github.com/mitchellh/cli.(*CLI).commandHelp(0xc0003dc140, 0x46a3fc0, 0xc00000e020, 0x46f8840, 0xc000b0d3c0)
	/go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:575 +0x894
github.com/mitchellh/cli.(*CLI).Run(0xc0003dc140, 0xc0003dc140, 0xc000b0c000, 0xc0009a1f10)
	/go/pkg/mod/github.com/mitchellh/[email protected]/cli.go:265 +0x227
github.com/hashicorp/waypoint/internal/cli.Main(0xc000a43700, 0x2, 0x2, 0x0)
	/home/circleci/project/waypoint/internal/cli/main.go:97 +0x4ee
main.main()
	/home/circleci/project/waypoint/cmd/waypoint/main.go:14 +0xa2

Steps to Reproduce

waypoint config

Expected behavior

waypoint not panicking

Additional context
Add any other context about the problem here.

Can't build without access to horizon

Describe the bug

$ make

GOOS=linux GOARCH=amd64 go build -o ./internal/assets/ceb/ceb ./cmd/waypoint-entrypoint
go: github.com/hashicorp/[email protected]: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /Users/sethvargo/Development/go/pkg/mod/cache/vcs/a38e1ee4d53b5cc1b45f57a15239484aa2dabd9dfa13965ab610b821635c82dc: exit status 128:
	remote: Repository not found.
	fatal: repository 'https://github.com/hashicorp/horizon/' not found
make: *** [bin] Error 1

Waypoint destroy command doesn't work for AWS ECS plugin

Describe the bug
The waypoint destroy command doesn't destroy the AWS ECS infrastructure creating when using the aws-ecs plugin.

waypoint destroy
» Destroying releases...
» Destroying deployments...
! Error destroying: rpc error: code = Unknown desc = ValidationError: A target group ARN must be specified
  	status code: 400, request id: 644db8e1-1d17-42d7-9fb0-6363195f8e72

Steps to Reproduce
Run through the ECS example in the hashicorp/waypoint-examples repo. Run waypoint up and then run waypoint destroy to clean the infrastructure.

The waypoint.hcl configuration file is as follows:

project = "example-nodejs"

app "example-nodejs" {
  labels = {
    "service" = "example-nodejs",
    "env" = "dev"
  }

  build {
    use "pack" {}
    registry {
      use "aws-ecr" {
        region = "us-east-1"
        repository = "waypoint-example"
        tag = "latest"
      }
    }
  }

  deploy {
    use "aws-ecs" {
      region = "us-east-1"
      memory = "512"
    }
  }
}

Expected behavior
waypoint destroy command cleans the infrastructure created by Waypoint.