Login in to the box with linci installed, if you get the linci shell prompt
linci> create build myprojotherwise prefix all the commands in this doc with
linci, or type
linci shellto enter the shell.
create build commmand will open vi with a template to be edited.
The first two targets must be
description:descriptive text that is shown when you type
environment:may be blank, if populated linci sources a
/var/linci/environment/before targets are run.
init:by convention this is the target that checks out the repo, e.g.
git clone https://github.com/me/myproj
clean:by convention this command wipes artifacts generated in the workspace, e.g.
targets::entry is required, it separates one-shot targets from the main build.
From here on target are free form, the following is a typical build
sync:get latest code from the repo, typically something like
git pull && git reset --hard origin/master
build:compile the code, typically
makeor run some grunt tasks, ant or maven
test:tests that have no external dependencies
publish:make code / binaries available outside the server
After creating the build, initailise the workspace with.
linci> build myproj initi.e. run the
inittarget on its own.
linci> build myproj
You will notice a surprising lack of output, generally scripts would be triggered by changes in source code, or run by cron by putting
linci build myproj in crontab. Notification if the build was successful or failed is done via IRC.
When you first setup a build it is useful to get immediate feedback, rather than watching IRC.
linci> ttyontells linci to echo success or failure messages to the shell, similar to the
wallutility. On a busy server
ttyoncan result in so many messages using the shell is impossible so console output is off by default.
ttyofftuns off console notifications.
Each build generates logs, you can tail the log of the last build stated on the console with the
llog command, to follow the log use
llogf. To view the logs of past builds you can use the
linci news utility which respects the
PAGER environment variable. If you prefer, grep, vi or emacs, the logs are flat files on the server, no special tools are needed for debugging linci runs. This is kind of the point, logs are not in some stupid XML format. Each build generates a file called
package:create tar.gz or deb or rpm
install:install the code locally
deploy:install the code remotely
inttest:run integration tests, test with external dependencies
promote:push to another environemnt
Jobs are simplified builds that have one target called command.
description: a test job run by testbuild environment: command: echo "hello world"Jobs are executed with.
linci> run myjob