We’re very excited to announce that Okteto’s Github Actions are now publicly available 🎉!
With our new Github Actions, it’s easier than ever to build a continuous delivery pipeline to deploy your applications directly into Okteto Cloud.
After close to a year in beta, Github Actions are now finally generally available. If you haven’t heard of it, GitHub Actions is an engine that lets you compose very powerful workflows in reaction to almost every type of GitHub event. Instead of writing lots of scripts like in Jenkins or CircleCI, you instead create your workflows by connecting a series of actions (e.g. checkout, docker build, push to the cloud), and passing context between them. They even have a visual editor to write them. Very cool stuff.
In this post, we’ll show you how you can use our new actions to create a workflow to deploy a new version of your application to Okteto Cloud after every commit.
The first step in using GitHub Actions is to create a workflow. You can do this from the Actions tab of your GitHub repository. This is where you define what will trigger a run of your workflow. There are several templates you can choose from, but for now, click on the
Set up a workflow yourself button on the right.
This will create a new file in your repository at
.github/main.workflow with the following contents:
As you can see, the workflows live right on your repository, under the
.github workflows. This allows you to iterate on them just like you would do for any other piece of code.
If you save the file right now, you’ll have a workflow that check’s out your code and prints an echo message. But don’t save it just yet. In the rest of the post, we’ll show you how to build a pipeline that builds your application, updates the necessary Kubernetes manifests and deploys it to Okteto Cloud.
The first action block we’re going to be adding will log us into Docker Hub, so that we can build and push Docker images.
- name: Login
For this, we’re going to be using official docker action. The
name is an identifier we give to the step. The
uses line specifies which action will run in this step. The name matches its location in Github. In this case, you can find the action at http://github.com/actions-hub/docker.
You’ll notice that we’re using a special notation to pass the value of
DOCKER_PASSWORD. Instead of hardcoding the value, we’re using secrets to securely pass those values to the action. The content of the secrets are configured in the
Settings of your repository, inside the
To generate your
DOCKER_PASSWORD, login to your Docker Hub account, go to the security section in your profile and click on the
New Access Token button.
To build the image, we’re going to be using the
okteto/actions/build action. This action leverages Okteto Cloud’s BuildKit as a Service, which is a lot faster than your traditional docker builds. In this case, the action will build the image and push it to Docker Hub.
- name: Build
This action needs an Okteto Cloud API Token to connect to the build service. You’ll need to add the
OKTETO_TOKEN secret to your repository. To get the value of the API Token, login to Okteto Cloud and go the Settings section.
You’ll notice that we are using the
sha of the commit that triggered the workflow as the image name. We do this to guarantee that every commit generates a unique image. This is one of the variables available in the Action’s context.
Now that we have an image built and available in Docker Hub, it’s time to deploy our application. First, go to Okteto Cloud and create a namespace. This is the namespace where your application will be deployed.
Once the namespace is created, add the following step to your workflow (don’t forget to change the namespace name):
- name: Get Kubeconfig
okteto/actions/namespace action logins to Okteto Cloud with the API Token and retrieves the
kubeconfig credentials needed to access the namespace. The step will set the location of the
kubeconfig file as an output of the step so that other actions can consume it.
Next, add a step to deploy your application:
- name: Deploy and Wait
okteto/actions/deploy action performs four things. It creates a
kustomization.yaml file on the fly to replace
ramiro/hello-world:0f71be2695f1c5148f465c5473c864591793540b in the specified manifest, processes the kustomization, deploys your application, and waits for the specified resource to be ready via the
kubectl rollout status command. If the specified resource is not ready in 300 seconds, the action will fail the workflow.
Finally, we’ll add the following step to verify that your application is responsive:
- name: Verify
srt32/uptime action will make an https request to the specified endpoint. We’re leveraging Okteto Cloud’s Automatic SSL endpoints to test accessing our application over the internet, just like our customers would. If the request fails or doesn’t return a status code
200, it will fail the workflow.
Start Commit at the right, type a commit message and commit the change to your master branch. From now on, every time someone pushes a commit, the
CI workflow will be triggered, and your application will be automatically built and deployed.
You can see the full workflow in action here.
This workflow is not constrained to any specific branch or commit type. This is great for testing, but in a typical setting, you’d want to only trigger this particular workflow on merges to your
productionbranch. Check out Github Action’s documentation to learn more about this.
Github Actions allows you to create very powerful workflows by linking together different actions. With our new Okteto Actions, you can easily incorporate Okteto Cloud resources into your CI/CD workflows.
Here are a few more resources to help you get started:
- The source code of our actions.
- GitHub Actions Documentation.
- Github Actions Markeplace.
- Okteto Cloud features.