Learn how to use artifacts in order to share information between jobs, and make them available for download.

Builds are the central component of MonkeyCI. They are the whole reason you're using this tool! Every time a change is detected in one of the configured repositories, a build is triggered. If you have set up a build script in the .monkeyci/ directory, it will be executed as a single build.

Where artifacts can be used to pass files between jobs, caching is meant to pass files between the same job, over different builds. Jobs that specify a caching entry with the same id will restore the files pointed to in their configuration before they start, and store it back after they have finished.

TODO

A build script consists of one or more jobs. There are two kinds of jobs: action jobs and container jobs. A job can be dependent on other jobs, which is indicated in the job configuration. In addition, jobs can require or produce artifacts, or they can use caches.

Labels are used extensively throughout MonkeyCI to group several kinds of objects for various purposes. The main applications for labels are:

Sometimes you just need to run something on your local machine. This is of course not advised for production purposes, but every once in a while, it can be useful to run the full build pipeline on your own machine. MonkeyCI makes this possible, as long as you either have Docker or Podman on your machine.

Build parameters are a way to configure your builds, without having to put this configuration in your build script itself. It is typically used for sensitive information like credentials or signing keys.

This is a listing of the available functions when writing build scripts. Since MonkeyCI is open source, you can also check out the code and see for yourself. The API code is located in the monkey.ci.build.* namespaces. They cover a range from low-level to high-level functions. It is advised to use the high-level functions in monkey.ci.build.v2, unless you want to do something very specific, in which case you may also find useful functions in monkey.ci.build.core or any other adjoining namespace.

For any publicly accessible application, security is important. MonkeyCI is no different. We generally advise against using any kind of sensitive or private information in your builds. Similarly, it's a bad idea to commit that information in your repositories, especially if they're public. But we also realize that in order to do decent integration tests or deployments, it's often unavoidable to put credentials or ssh keys in build parameters. MonkeyCI ensures that this information is only visible to the appropriate users. To this end, the build parameter values and ssh keys are encrypted at rest. This means they are stored in an encrypted manner in the database. It's only when editing them or when using them in a build that they are decrypted.

TODO

As with all coding, or actually, with everything, you want to test things before you roll them out. Similar to your production code, which of course you write using TDD, you'd want to be able to write tests for your build script. After all, it may be important. When you're writing things thay may deploy directly into production, it seems self-evident to test this thoroughly before running it against a live environment.

TODO