Getting started

A simple continuous integration server implementation without tedious configuration. Just send your request to Cimon to see your tests run and test your build on a dedicated virtual machine independently.

All one has to do is to send a sign up request to Cimon.

Don’t forget to authorize via GitHub and allow Cimon to access GitHub on your behalf as your next step.

Once the authorization is completed - feel free to choose one and more projects you need Cimon for.

Be sure your project has .cimon.yml file. You need .yml file to let Cimon know configurations of your projects.

File structure.

.cimon.yml file describes the application settings, and services needed for the build and test execution. Cimon needs to know services and processes it needs to execute.

Services

Cimon needs to know services (and their Docker images) we need to build and to test the application.

For example: services: postgresql: from: postgres

Cache

Cimon lets you to save service data between builds. Simply include the service in the same list, indicating the folder to be cashed under the cache entry.

This folder path goes to the project root.

      services:
         postgresql:
            from: postgres
         cashed_postgresql:
            from: postgres
            cache:
              - /var/lib/postgresql/data

Services for each process are cached in a separate folder.

build

Cimon doesn’t limit you to standard tool set. If you need to install additional tools to go with the service, you can list them under the buildentry of the corresponding service. They will be executed before the start of the service just once and will be cached for the future builds.

      services:
         rails:
            from: ruby:2.1.1
            cache:
             - /bundle
             - /app/public/assets
            build:
             - apt-get update
             - gem install bundler

Please note, with Cimon you can use any kind of services available for Linux.

Processes

Here all the magic starts. Cimon executes every process independently on a detached machine for you to watch how tests pass and while playing around the implementations on the staging server(s) set up instantly.

Default settings

service Call for services needed to start a process.

folder Indicates the location, from where the process is started

cmd Indicates specific commands for your process.

Additional settings

prepare Specify all commands to be executed every time you run the tests.

dependencies The location for dependencies to be available to the application.

env Environmental variables.

port The address, which Cimon can make available online.

How the magic works.

Cimon takes care of your application. You don’t need to make changes inside the project to let it know it uses Cimon. All you need is to leave the project as is and tell Cimon what to do.

As soon as you are ready to test your implementation before it is merged, go and say Cimon to start.

Cimon first reads and executes configurations specified in .cimon.yml file. Cimon sets up the environment your project needs. You easily track installation process. Once the environment is installed on a dedicated virtual machine Cimon skips installation process every time we start a build until a change is made in services section in the conf file.

As soon as a step is passed, Cimon runs processes according to the config. Now you get your staging server(s) run on a detached machine and tests passing separately.

Watch your tests. By navigating through your Cimon panel, feel free to see tests history, tests status, etc.

Visit your staging server by clicking on a corresponding subdomain.

Creating Subdomains

Each port has its own subdomain. For example:

61356ci.cimon.pub:80

The name of the subdomain is generated based on a process name and on on a unique ID of a pull request. If port is indicated for only one process within one pull request, the subdomain name is generated based on a unique ID of a pull request.

If at least two processes have the port or ports entry, or there is more than one pull request, a separate subdomain is created for each process. If there is no port or ports entry in the processes section, no subdomain is provided.

You’ve just tested your implementation on a staging instance and has found a room for improvements - feel free to make any change. Cimon picks up the changes automatically. As soon as a piece of code is pushed to the repository, Cimon is being aware of this fact.

If your tests pass or fail Cimon will let you know.

How does Cimon do it? Easily!

Webhooks

Cimon traces the changes in the repository by webhooks. Webhooks are delivered using HTTP POST.

To identify changes in services Cimon uses SHA-1 hashes.

Just as any Unux system does, your test processes return exit status. This way the tests are considered as passed once Cimon gets 0 as a return code. Otherwise, Cimon notifies you that the tests fail.

Emails

By default, email notifications are sent to all collaborators of the repository when the build has passed or failed the tests.

FAQ

Can I Perform Staging in a Master Branch?

Yes. To perform staging in a Master branch, create a pull-request from ‘master’ branch. After the staging is complete, the branch can be merged to production.

Can I Create Separate Child Processes within a Process?

No. It is impossible to create separate child processes and make one of them refer to another.