VexorCI: how we prepare configuration files

Hello!



When VexorCI started, we decided that it was not necessary to write a configuration file to start using. We ourselves are trying to guess what exactly is needed to run the tests and constantly teach the service to recognize the new settings. But the development world is very diverse, so some projects need configs.

Over the past couple of months, 100 projects have joined the Vexor. Very different projects with unique settings. During this time, we learned a lot about how to prepare configuration files so that it is convenient for our users. In the process, we have revised our initial approach and want to share with you the innovations.

We have remade the generation of scripts to run.

In order to understand what tasks need to be performed to prepare the environment and run tests in VexorCI, use the configuration file vexor.yml. This file is located in the root of the repository, or is generated automatically. It specifies the commands that will be executed to prepare the test environment and run the tests.



Earlier, in order to convert vexor.yml directly into commands that the worker performs when running tests, we:

')

1. Received a build config;
2. Parsed it;
3. Generated a large bash script;
4. Sent the script to the worker.

With this scheme, there were a lot of problems:

• Nontrivial things were very difficult to do, for example, patching the config / secrets.yml in a Rails application.
• Bash is not the most successful language for writing large amounts of code, there were a lot of hard-to-find bugs.
• Incomprehensible to the user error messages.

We decided to remake it. Now we:

1. Get the build configuration in yaml format;
2. We convert the intermediate representation into a file, also in the yaml format. The file structure itself is made by analogy with the ansible (example here ).
3. This file is sent to the worker for execution.

The refusal to generate a giant shell script allowed us to more flexibly manage the deployment of the environment, show our users understandable error messages and forget about difficult to fix bugs in the shell.

We slightly changed the key assignment in the configuration file.

To start using VexorCI, it is not necessary to write a config. We ourselves are trying to guess what exactly is needed to run the tests. Unfortunately, in the old version there were situations when the tasks generated by default clashed with the tasks specified by the user in the configuration file.



In order to further avoid such conflicts, all settings related to databases that were previously in the 'before_script' key should now be in a separate key - 'database'.

#  before_script: - rake db:create - rake db:migrate #  database: - rake db:create - rake db:migrate 

Using a separate key for the database makes the configuration easier and clearer.

We added support for CCMenu .

CCMenu is a popular application that displays build statuses in the toolbar and allows you to be always aware of what is happening on the CI server. Now projects from VexorCI can be easily added to CCMenu.



Go to the project's “Settings” page and copy the “CCMenu URL.”







Insert url in the feed url field







Works!







Now it is even more convenient to track build statuses.



By the way, we have another great news: 100 minutes of tests every month became free. Join now!