A CI server written in Erlang.
NOTE: I'm NSWIDY (Not Sure What I'm Doing, Yet). But please, feel free to Not-Sure-What-I'm-Doing-Yet with me!
Edit config/sys.config and
change config
so it points to your own config file.
See examples/config.yml.
See examples/jobs/my_job/config.yml.
Config files can include variables (actually, they are parsed as mustache template files). For example, your main config file could be something like:
# ... other config options...
variables:
shell: /bin/bash
bash: {{shell}}
So the variable bash
will be equal to the value of the variable shell
. Then,
in your job config file:
# ... other config options...
variables:
my_shell: {{bash}}
phases:
# ... other phases...
create_artifacts:
main:
type: cmd
config:
shell: {{my_shell}}
executable: /usr/bin/tar
args:
- zcf
- artifact.tar.bz2
- "*"
As result, global variables declared in your main config file are also available in the configuration file of your jobs.
The build goes through different phases
in order, you can see all of them
here.
It's not necessary to have all of them setup in your job's config file, and the build will skip the ones missing. You can configure the different build phases like this:
# ... other config options...
phases:
# ... other phases...
fetch_source:
main:
type: git
config:
executable: {{git_location}}
repository: https://github.com/marcelog/erlci
fetch_dependencies:
main:
type: rebar
config:
source_directory: {{src_dir}}
executable: {{rebar_location}}
# ... other phases...
In this case, two phases are shown (fetch_source
and fetch_dependencies
),
each one with just 1 step called main
in both cases.
The name of the step is anything you'd like, it's just a description useful
for you when configuring the build. Steps are run in order of appearance. Each
step will run a plugin, defined with the type
key. The config
key will
depend on a per plugin basis. Current available plugins:
- rebar: Uses rebar to run different tasks on the source, can be used in many different phases.
- git: Uses git to fetch sources.
- cmd: Runs a shell command.
Triggers can be setup in your job config file like this:
name: my_job
# ... other config options ...
triggers:
git_poll:
expression: "*/1 * * * *"
executable: {{git_location}}
repository: {{repo}}
source_directory: {{src_dir}}
cron:
expression: "*/1 23 * * *"
phases:
# ... your phases and other config options here ...
Triggers are useful to automatically start a build of your job in many different situations. The current available triggers are:
- cron: Takes a Vixie cron-like expression in order to trigger a build.
- git_poll: Given a Vixie cron-like expression, polls a GIT scm and starts a new build if there is a new revision.
make run
BuildDescription = erlci_build:describe_build(
"user", "marcelog", "manual trigger", "a nice build description"
).
erlci_build_monitor:start_build("my_job", BuildDescription).
The build will generate a log.txt
file inside the workspace of the build (e.g:
/tmp/erlci/workspace/my_job/BUILD_NUMBER/log.txt).
You can write plugins to extend the build process with new features, for a few examples see: src/plugins.
The source code is released under Apache 2 License.
Check LICENSE file for more information.