Adding Your First Project
Last updated
Last updated
This page contains a simple guide to help you get started with Garden Cloud and become familiar with its main concepts.
Log in to Garden Cloud and follow the instructions on the page to add your first project.
Once you've added the project, click on it, and take note of the project ID and domain:
If you haven't configured this project for Garden before, you'll have to do that before proceeding.
Next, go the project level garden.yml file for this project and add the ID and domain as top level keys, for example:
Once you've added the ID and domain to your project, you can log in to Garden Cloud from the Garden Core CLI by running:
Follow the instructions on the screen to complete the log in.
The Garden Core CLI is now connected to Garden Cloud, and can read secrets and stream events and logs.
You can bypass the manual log in flow, e.g. if you're running Garden Core from a CI environment, by generating an access token for the user you want to log in as from the Teams page.
Once you've generated the token, set it in your environment like so: GARDEN_AUTH_TOKEN=<my-generated-auth-token>.
Go to the project's Secrets page and create a secret called MY_TEST_SECRET:
(We'll be printing this secret later so use a fake value).
Secrets can be project wide, scoped to a specific environment, or scoped to a specific environment and a specific user. Garden will resolve the secret to the correct value at runtime.
If you don't see the environment you're looking for in the environment dropdown, you can create it by running a Garden command in that environment while logged in, or from the project's Settings page.
Next, create the following workflow for your project:
Make sure to use one of your own environments in the
triggers[].environmentfield.
This is a simple workflow that just prints the secret value. For a more comprehensive guide on configuring workflows see our core docs, and for a guide on configuring workflows specifically for Garden Cloud, see here.
The triggers spec is specific to Garden Cloud and tells it to run this particular workflow in the ci environment (or the environment that you specified) on VCS events of type pull-request. I.e., when you open or update a pull/merge request on GitHub or GitLab.
Now, try running the workflow from the command line:
You'll see the output of the secret you created in the Garden Cloud UI locally.
And the workflow run should now also be visible in the Garden Cloud UI under > Namespaces > > Workflow runs:
You can click the logs icon next to the workflow run to see the actual result:
Finally, let's open a pull/merge request with our changes and see how Garden Cloud automatically runs the workflow.
This is where the triggers spec we defined above comes into play.
Commit your changes, push them to GitHub/GitLab and open a pull/merge request.
As soon as you do that, Garden Cloud will proceed to clone the branch, validate your configuration and run this workflow. On GitHub, you will see checks that report the status of the workflow. On GitLab you will see status updates reported via comments.
Garden Cloud also sends the service endpoints it finds to GitHub/GitLab so that you can view the preview environments that may have been deployed, straight from the pull/merge request page.
As with the workflow you ran locally, this workflow run is also visible in the Garden Cloud UI, under the environment and namespace in which it ran.
Now that you're familiar with the basics of Garden Cloud, you can proceed to add more of your team members from the Teams page.
You can also look at our workflow configuration for more information on configuring triggered workflows, deploying preview environments and cleaning them up.
