Space Automation Is Available for Everyone
Space Automation, one of the most popular planned features among our early adopters during the EAP, is now available to all Space Beta customers.
With Automation, you can run your CI/CD activities in Space to build, test, and deploy your project.
Space is now in Beta and is available for free to everyone. All Space Beta customers are provided with the Organization plan, which includes 10,000 CI credits per month. If you haven’t joined our Beta program yet, sign up for Space for free and start using it today.
We’ve prepared a brief overview of the system to help you get started automating a wide range of tasks and organizing your continuous delivery pipelines.
Without further ado, let’s talk about Automation!
What is Space Automation
Automation is the Space module responsible for all CI/CD activities in the system. You can build, test, and deploy a project, using the script file stored in its repository.
Configuration as code
Scripts are the only way to configure Automation. The Automation UI you see in Space is used only for visualizing script results: logs, tests, artifacts, and so on. Scripts are written in a special Kotlin-based DSL (domain-specific language).
The automation script must be stored in the .space.kts file in the root directory of a project. To edit .space.kts, you can use either the Space code web-editor or IntelliJ IDEA with the Space plugin installed.
The Space Automation DSL is based on Kotlin (YAML is planned), which has a lot of advantages – you can use Kotlin data types and language structures right inside your automation script.
Isolation in a branch
Because you configure Automation through the script file, the configuration is fully isolated within a Git branch. This makes it very easy to experiment with Automation scripts: just create a new branch, add the .space.kts file, and start experimenting.
All Automation activities run inside Linux-based Docker containers. The building blocks of Automation scripts are jobs. A job lets you run independent steps inside containers. In our example, the job consists of just one step: an Ubuntu container that runs a shell script.
Job run results and container logs are shown on the project’s Jobs page:
Sequential and parallel steps
You can run steps inside containers both sequentially and in parallel. This allows you to run a graph of containers.
Running Kotlin code
Kotlin-based DSL lets you implement complex logic inside your build scripts. For this purpose, you can use a special kotlinScript item inside a container.
Integration with other Space modules
.space.kts has access to the Kotlin-based Space HTTP API client. All Space modules provide APIs, so you can communicate with all of Space:
- and so on.
Integration with Gradle, Docker, and other tools
We provide additional step types as well as APIs to help you work with external tools. For example, you can use the gradle or gradlew steps to simplify Gradle builds:
The output of tests is shown on the job overview page:
You can use the docker step to build and push Docker images:
Later, we plan to add support for .NET, npm, MVN, and other tools.
Using external libraries
Another advantage of using Kotlin for your Automation scripts is that you can reference external libraries.
IntelliJ IDEA plugin
You can use the Space plugin for IntelliJ IDEA to make it easier to write complex scripts that use Space APIs. In addition to checking your Automation scripts, the Space plugin also provides you with automatic code completion.
Integration with Space Packages
Space Packages is the universal repository manager built into Space. It supports a variety of repository types – container registries, Maven repositories, NuGet feeds, and npm registries. Automation provides integration with Packages out of the box:
- Your Automation scripts don’t require authentication.
- A package version can be automatically changed according to the job execution number.
Inside containers, you can run additional service containers that provide network-accessible services, such as MySQL, Redis, Elastic, and more.
As with any other container, you can view service container logs:
You can use a file share to pass build artifacts from one step to another. A file share is a special volume mounted to each container that you can access either directly or using a special API.
Secrets and parameters
One important part of any CI/CD system is the ability to securely store credentials to various external resources, like an external package repository, for example. For this purpose, Automation provides its own storage for secrets and parameters:
Secrets and parameters can be easily accessed from .space.kts using key values.
Each JetBrains Space subscription plan includes a certain number of CI credits, an artificial currency that is spent when you run your Automation builds. One CI credit is equal to one minute of work of a default Linux container (2 vCPU, 7800 MiB RAM). Each month your CI credits are restored. Each subscription plan includes not only a certain number of CI credits but also a certain number of Reserve credits – your safety stock of CI credits. After you have spent all your monthly CI credits, Automation will disable automatic job triggers in all repositories (for example, a trigger activated by ‘git push’). After the automatic job triggers have been disabled, you can only trigger a job manually by running it on the Jobs page. Reserve credits will be used to pay for the execution of these jobs.
Here is the recording of Introduction to Automation: CI/CD in Space webinar:
During this session, JetBrains Developer Advocate Maarten Balliauw introduced many of the concepts behind Space Automation. He also discussed the automation DSL, running builds, publishing to the Space package registry, secrets and parameters, and much more! Evgeniy Koshkin, Automation Team Lead, hosted a Q&A session after Maarten’s talk.
Well, that’s all for today. We hope this has given you a nice overview of the Automation concept in Space.
Please feel free to ask us any questions you have or share your thoughts in the comments below.
The JetBrains team
— The Drive to Develop