Lifecycle Jobs, Cronjobs, Last Goodbye to the V2...

Happy New Year from the whole Qovery team!✨🥳  We hope everyone had a wonderful holiday season and is ready to start the new year off with a bang.
To kick things off, we have a new changelog for you, filled with updates and improvements we've made over the past few weeks.
These updates will make your experience with our product even better. As always, we welcome your feedback and suggestions, so please don't hesitate to contribute to our Public Roadmap or contact us on the Forum if you have any thoughts or ideas.
Thank you for your continued support, and here's to a successful and productive year ahead!

#Lifecycle Jobs

In this repository, Romaric shows you several ways you can use Lifecycle Jobs, which include:

• Call HTTP endpoint when an Environment is created
• Create and Destroy an AWS RDS instance with Terraform
• Create and Destroy an AWS Lambda with Serverless
• Create and Destroy an AWS EC2 instance with Pulumi

Lifecycle jobs run on a Kubernetes cluster and are executed only when a specified event occurs in the environment. The output files created by the job will be automatically set as environment variables for services within the same environment. These types of jobs are useful for tasks such as seeding a database or creating external resources not natively managed by Qovery.

Qovery allows you to create and deploy jobs from Git Repository or Container Registry.

#Cronjobs

Alessandro, Lead Product Manager at Qovery, joined me during our November Demo Day to talk about Cronjobs, as it was highly expected by most of you. While the development of this feature just started then, I have the honour to inform you that Cronjobs are now available! 🤩

A cronjob is a type of workload that runs on a Kubernetes cluster on a regular schedule. It can be used to execute tasks on a regular basis, such as pulling data from an external service every hour or processing data in a database. Qovery allows users to create and deploy Cronjobs from either a Git repository or a container registry.

To know more about it, check out our documentation!

#Last Goodbye to the V2

As of today, our V2 platform has been partially shut down. Any actions related to environments, projects, or services should now be performed on the V3 platform. We are pleased to announce that the cluster list page is now also available on the V3.

And a big shout-out to our Frontend, Product, and Design teams for their hard work in making this transition as smooth as possible.

If you want to learn more about the V3, here is the first-ever demo we made of it when it went out this summer 👇🏻

#Environment Variables Interpolation

You can define an environment variable as a composition of text and other environment variables value (environment variables interpolation). For example, you can define your APP_URL environment variable as a composition of your HOST_URL and HOST_PORT in this way:

Name = APP_URL Value = https://{{HOST_URL}}:{{HOST_PORT}}

To learn all the important informations about this new feature, check out our documentation!

#Pumped CLI

Our CLI has been pumped as a lot has been added to it, such as commands for:

• Application (list, deploy, redeploy, stop, delete, cancel)
• Container (list, deploy, redeploy, stop, delete, cancel)
• Environment (list, deploy, redeploy, stop, delete, cancel, clone)
• Job (list, deploy, redeploy, stop, delete, cancel)
• Database (list, deploy, redeploy, stop, delete, cancel)

#Kube 1.22 Upgrade

Each cloud provider has a limited number of supported Kubernetes versions, if you were to use Kubernetes without Qovery, you would have to do the upgrades yourself, but one of the benefits of using Qovery is that we manage it for you!

In my last Changelog, I explained you that the goal was to pass every cluster to version 1.22, and for that, we had a plan of action that you can find on this dedicated page on our forum, as of today, all the clusters have been migrated! 🎉

#New Built-in Environment Variables

It’s not one but three new built-in Environment Variables that has been added and let me show which ones:

• QOVERY_CLOUD_PROVIDER_REGION: indicate the region where the cluster is running
• QOVERY_KUBERNETES_NAMESPACE_NAME: indicate the Kubernetes namespace name where the current service is running
• QOVERY_KUBERNETES_CLUSTER_NAME: indicate the Kubernetes cluster name where the current service is running

#Smaller Improvements and Fixes

• Timezone switch on logs
• Removed unity of mesure