Continuous Integration


CI / CD stands for continuous integration and continuous delivery. Generally spoken, those terms are describing a standard way to build, test and ship software automatically. A typical and famous tool to realize such an automation is Jenkins.

In the world of Open Source, Cloud and Github, another famous system developed, which has the very big advantage of a good integration with GitHub, as well as good integration of C, Go or Java compilers. So for a big range of projects, it is a natural fit.

CODESYS and Drone

Drone is an impressing project. It focuses mainly on providing a perfectly integrated CI / CD system for GitHub. But, as the engine is open source, you can also create your own installation of it.

Such an installation is now integrated into CODESYS Forge. It is used in the backend to build CODESYS projects, build CODESYS packages, run Unit Tests or deploy the packages to CODESYS Forge.

Pipelines and Staging

The main concept of most CI / CD systems is, to separate at least build, test and deploy processes into separate steps. But in practice you often need even more steps in your pipeline.

For example:

  • Build: Compile a CODESYS library
  • TestBuild: Create a Bootapplication of a testproject with the library
  • TestExec: Run the test application on a SoftPLC, like CODESYS Control for Linux SL
  • Deploy: Push the Library to an FTP server

This is an easy, but real world use case for a CI / CD system. And while it's easy to understand, it shows a few important concepts, every user of a such a system should be aware of:

  1. Every step depends on a successful previous step. So the pipeline stops when one of the steps fails.
  2. The different steps need different tools.
  3. Build and TestBuild need CODESYS
  4. TestExec needs CODESYS Control
  5. Deploy needs an FTP client

The first concept is known as pipelining, because everything is executed sequentially in a pipeline. The second step is known as staging, because every step is working on the same workspace, but with a different environment. This environment is seen as the stage on which the step of the pipeline takes place.

Build Artifacts

A build artifact is an output file, which was created during a build step. It can be an executable, a script, a library or even a complete package (nuget, npm, CODESYS Packages, ...). Many CI / CD systems (including Jenkins) define build artifacts to be passed between different steps of the pipeline.

Drone doesn't do that. It simply passes the whole workspace from stage to stage. With drone, build artifacts are collected in the last stage of a build pipeline. This stage is typically called, the deploy stage.

On CODESYS Forge, you just need to copy all files which you want to preserve into the subdirectory ".drone-artifacts" of your repository. Drone on CODESYS Forge will the serve those files under the URL "/download/<repository-name>".</repository-name>

The name of the URL is choosen by purpose, as you may serve those files directly to your users. The access rights to the files are the same as the rights to the repository.

Download Links

If you now fear, that we repack your software and serve it to your users without your acknowledge, I can give you the all-clear.

We do build packages, but we don't link them anywhere. You can only find the links in the admin page of your projects.

Example Pipeline

By default, we use a generic drone configuration to build all repositories, which don't have one. This configuration is doing the following:

  • Compile Libraries
  • Extract Library Source Code
  • Create Packages
  • Build Packages

The built package is the served as a build artifact.

You can customuze this automatism, by providing your own files for the different steps:

  • provide your own package.manifest, to have control over the content of your package
  • provide your own .drone.yml in the root of the repository

An example .drone.yml might look like this:

kind: pipeline
name: default
  base: /working
  - name: compile
    image: codesys-ide:local
      - codesys compile-library
      - find -name \*.compiled-library -exec cp {} .drone-artifacts/ \;

Trigger and build time

The build will be triggered whenever you commit something into your repository. But the exact time when the build is started might vary from time to time. Roughly it should be around 5 to 30 minutes after the commit.