I want to use waypoint for my hobby projects. I don’t have a CI pipeline. I also dont want to have to manually check out my project just to build it and throw it away. Can waypoint pull source from github directly and read the waypoint.hcl ?
Welcome @thedewpoint!
In 0.1.x, the Waypoint CLI operates on locally accessible files. The waypoint init
command has a -from-project
option that enables retrieving remote content for the CLI to operate. The command makes it possible to use remote git as your system of record with a workflow like the following:
- Retrieve remote app files with
waypoint init -from-project
- Navigate into the project directory and invoke
waypoint init
- Perform whatever
waypoint
work you would like withwaypoint up
,waypoint logs
,waypoint exec
etc. - Delete all local files.
- Time goes by.
- Retrieve remote app files with
waypoint init -from-project
- Navigate into the project directory and invoke
waypoint init
. The project name and app name fromwaypoint.hcl
file already exist, so anywaypoint
commands issues modify that existing project and app. - Perform whatever
waypoint
work you would like withwaypoint up
,waypoint logs
,waypoint exec
etc.
For a full example see this gist using waypoint-examples/docker/static.
With 0.1, a simplified workflow would have to combine the steps above into a script or similar.
Can you describe your ideal workflow if this doesn’t work for you?
Thanks for the reply @jbayer! This is part of what I was looking for. The other part was triggering waypoint up upon a git commit. My thought was to tell waypoint where my project lived and when I committed a new file it would automatically rebuild and publish my image and then deploy to my kubernetes cluster if that makes sense. This is still very helpful though! Thank you
Ok, I was thrown off somewhat by your comment that you don’t have a CI pipeline. If you’re using Github already, then following this Waypoint in Github Actions documentation shows you how to have git commits that are pushed to Github trigger Waypoint activity. The example shows a couple of different flows. E.g. you can have the default git branch using a particular Waypoint workspace (say development) and then when you push commits to a release branch you can use a different Waypoint workspace (say representing production).
This approach moves the Waypoint CLI execution from your workstation to Github Actions. It requires a network reachable Waypoint Server and deployment target (ECS, k8s, etc) . The waypoint CLI that runs in the Github Actions environment will attempt to reach out to both the Waypoint server and the deployment target.