Hi, really glad to have waypoint in our lives, but there is something that we’ve somewhat met as a roadblock in adopting waypoint.
We initial believe the use of waypoint context for example with docker, allowed us to register waypoint servers with different docker engines hosted on remote servers, so that when we switch context and deployment is made, then that deployment is both either:
- Built locally then copied for deployment to the remote docker
- The data are sent to the remote engine, built, and deployed.
But when tested, the UI on the remote server did display the build process which was executed through the waypoint CLI, but with a surprise we find ourselves seeing the container deployed locally to our local docker engine.
Which was in its self a surprise, so I guess the questions are:
- Did we misunderstand contexts?
- Is the docker plugin coming with waypoint not able to deploy to the remote docker engine?
- Is there a way to achieve this? (Do we need to thinker around with docker environments variables?)
While researching, I found the following github PR ticket Docker Remote Engine by nicholasjackson · Pull Request #631 · hashicorp/waypoint · GitHub, but we don’t want to hardcode remote docker credentials into the waypoint file, it just makes it one off and brittle.
Would appreciate any insight possible.
On the contribution end, I find myself stuck trying to setup the nix packages as the golang 1.15 (roughly believe) fails to pass the test process after building, making it impossible for me to get running, and trying just normal
go mod tidy leaves with a few import errors on the project, are there any clear ways to bypass the golang build failure due to failing tests?
Could I suggest the execution of the golang building without execution of tests if possible.
I would very much like to contribute and any help to get running with the project dev side would be appreciated.