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.
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:
Every step depends on a successful previous step. So the pipeline stops when one of the steps fails.
The different steps need different tools.
Build and TestBuild need CODESYS
TestExec needs CODESYS Control
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.
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.
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.
By default, we use a generic drone configuration to build all repositories, which don't have one. This configuration is doing the following:
Extract Library Source Code
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