Archives/ohwgiles_laminar
1
0
Fork 0
mirror of https://github.com/ohwgiles/laminar.git synced 2024-10-27 20:34:20 +00:00
Code Issues Projects Releases Wiki Activity

README tweaks and fixes

Browse Source
This commit is contained in:
Oliver Giles 2017-09-02 11:51:44 +03:00
parent 11013ed893
commit 2475b0beee
1 changed files with 19 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
README.md
View File

@ -48,7 +48,7 @@ Use `systemctl start laminar` to start the laminar system service and `systemctl
After starting the service, an empty laminar dashboard should be available at http://localhost:8080 After starting the service, an empty laminar dashboard should be available at http://localhost:8080
Laminar`s configuration file may be found at `/etc/laminar.conf`. Laminar will start with reasonable defaults if no configuration can be found. Laminar's configuration file may be found at `/etc/laminar.conf`. Laminar will start with reasonable defaults if no configuration can be found.
#### Running on a different HTTP port or Unix socket #### Running on a different HTTP port or Unix socket
@ -137,7 +137,7 @@ On a trusted network, you might want `laminard` to listen for commands on a TCP
LAMINAR_BIND_RPC=*:9997 LAMINAR_BIND_RPC=*:9997
``` ```
or any interface/port combination you like. This option uses the same syntax as [that for the web UI](#running-on-a-different-http-port-or-unix-socket) or any interface/port combination you like. This option uses the same syntax as `LAMINAR_BIND_HTTP`.
Then, point `laminarc` to the new location using an environment variable: Then, point `laminarc` to the new location using an environment variable:
@ -215,14 +215,13 @@ See also [script execution order](#script-execution-order)
#### Passing variables between run scripts #### Passing variables between run scripts
Any script can set environment variables that will stay exposed for subsequent scripts of the same run using `laminarc set`. In `example.before`: Any script can set environment variables that will stay exposed for subsequent scripts of the same run using `laminarc set`. In `example.before`:
```bash ```bash
#!/bin/bash #!/bin/bash
laminarc set foo=bar laminarc set foo=bar
``` ```
Then in `example.run` Then in `example.run`
``` ```bash
#!/bin/bash #!/bin/bash
echo $foo # prints "bar" echo $foo # prints "bar"
``` ```
@ -231,9 +230,9 @@ This works because laminarc reads `$JOB` and `$NUM` and passes them to the lamin
### Post-build actions ### Post-build actions
Analagously to [Pre-build actions](#pre-build-actions), if the script `/var/lib/laminar/cfg/jobs/example.after` exists, it will be executed after the primary `/var/lib/laminar/cfg/jobs/example.run` script. The `$RESULT` environment variable will contain the run result. Analagously to [Pre-build actions](#pre-build-actions), if the script `example.after` exists, it will be executed after the primary `example.run` script.
See also [Environment variables](#environment-variables). The `$RESULT` environment variable will contain the run result. See also [Environment variables](#environment-variables).
#### Archiving artefacts #### Archiving artefacts
@ -299,17 +298,17 @@ The directory `/var/lib/laminar/cfg/scripts` is automatically prepended to the `
```bash ```bash
#!/bin/bash -e #!/bin/bash -e
if [ "$RESULT" == "success" ]; then if [ "$RESULT" == "success" ]; then
laminarc trigger $@ laminarc trigger "$@"
fi fi
``` ```
With this in place, the example shown above in [Conditionally trigger a downstream job](#conditionally-trigger-a-downstream-job) can be simplified to With this in place, any `.after` script can conditionally trigger a downstream job more succinctly:
```bash ```bash
success_trigger example-test success_trigger example-test
``` ```
Another excellent candidate for helper scripts is automatically [sending notifications](#email-and-im-notifications) on job status change. See [Example scripts](#appendix--example-scripts) for more useful starting points. Another excellent candidate for helper scripts is automatically sending notifications on job status change. See [Example scripts](#appendix-example-scripts) for more useful starting points.
### Data sharing and Workspaces ### Data sharing and Workspaces
@ -348,7 +347,7 @@ Laminar will automatically create the workspace for a job if it doesn't exist wh
In Laminar, a *node* is an abstract concept allowing more fine-grained control over job execution scheduling. Each node can be defined to support an integer number of *executors*, which defines how many runs can be executed simultaneously. In Laminar, a *node* is an abstract concept allowing more fine-grained control over job execution scheduling. Each node can be defined to support an integer number of *executors*, which defines how many runs can be executed simultaneously.
A typical example would be to allow only a few concurrent CPU-intensive jobs (such as compilation), while simultaneously allowing many more less-intensive jobs (such as monitoring or remote jobs). To create a node named `build` with 3 executors, create the file `/var/lib/laminar/cfg/nodes/build.config` with the following content: A typical example would be to allow only a few concurrent CPU-intensive jobs (such as compilation), while simultaneously allowing many more less-intensive jobs (such as monitoring or remote jobs). To create a node named `build` with 3 executors, create the file `/var/lib/laminar/cfg/nodes/build.conf` with the following content:
``` ```
EXECUTORS=3 EXECUTORS=3
@ -383,7 +382,7 @@ If `/var/lib/laminar/cfg/nodes/NODENAME.env` exists and can be parsed as a list
### Remote jobs ### Remote jobs
Laminar provides no specific support, `bash`, `ssh` and possibly NFS are all you need. For example, consider two identical target devices on which test jobs can be run in parallel. You might create a [node](#nodes and tags) for each, `/var/lib/laminar/cfg/nodes/target{1,2}.conf` with a common tag: Laminar provides no specific support, `bash`, `ssh` and possibly NFS are all you need. For example, consider two identical target devices on which test jobs can be run in parallel. You might create a [node](#nodes-and-tags) for each, `/var/lib/laminar/cfg/nodes/target{1,2}.conf` with a common tag:
``` ```
EXECUTORS=1 EXECUTORS=1
@ -411,20 +410,11 @@ ssh root@$TARGET_IP /bin/bash -xe <<"EOF"
uname -a uname -a
... ...
EOF EOF
scp root@$TARGET_IP:result.xml $ARCHIVE/ scp root@$TARGET_IP:result.xml "$ARCHIVE/"
``` ```
Don't forget to add the `laminar` user's public ssh key to the remote's `authorized_keys`. Don't forget to add the `laminar` user's public ssh key to the remote's `authorized_keys`.
The call to ssh can itself be hidden with a [helper script](#helper-scripts) `/var/lib/laminar/cfg/scripts/remotebuild`:
```bash
#!/bin/bash -e
ssh -E root@$TARGET_IP /bin/bash -xe < $1
```
Then simply use `#!/usr/bin/env remotebuild` instead of the `#!/bin/bash` hashbang.
### Docker container jobs ### Docker container jobs
Laminar provides no specific support, but just like [remote jobs](#remote-jobs) these are easily implementable in plain bash: Laminar provides no specific support, but just like [remote jobs](#remote-jobs) these are easily implementable in plain bash:
@ -432,7 +422,7 @@ Laminar provides no specific support, but just like [remote jobs](#remote-jobs)
```bash ```bash
#!/bin/bash #!/bin/bash
docker run --rm -ti -v $PWD:/root -v $WORKSPACE:/ws ubuntu /bin/bash -xe <<EOF docker run --rm -ti -v $PWD:/root ubuntu /bin/bash -xe <<EOF
git clone http://... git clone http://...
... ...
EOF EOF
@ -464,7 +454,7 @@ laminarc lock $JOB-workspace
git fetch git fetch
git checkout $rev git checkout $rev
cd - cd -
# Fast (hard-link) copy the specific checkout to the build dir # Fast copy (hard-link) the specific checkout to the build dir
cp -al $WORKSPACE/src src cp -al $WORKSPACE/src src
# Release the lock to allow other jobs to do the same # Release the lock to allow other jobs to do the same
laminarc release $JOB-workspace laminarc release $JOB-workspace
@ -506,12 +496,12 @@ When `$JOB` is triggered on `$NODE`, the following scripts (relative to `$LAMINA
The following variables are available in run scripts: The following variables are available in run scripts:
- `RUN` - `RUN` integer number of this *run*
- `JOB` - `JOB` string name of this *job*
- `RESULT` - `RESULT` string run status: "success", "failed", etc.
- `LAST_RESULT` - `LAST_RESULT` string previous run status
- `WORKSPACE` - `WORKSPACE` path to this job's workspace
- `ARCHIVE` - `ARCHIVE` path to this run's archive
In addition, `$LAMINAR_HOME/cfg/scripts` is prepended to `$PATH`. See [helper scripts](#helper-scripts). In addition, `$LAMINAR_HOME/cfg/scripts` is prepended to `$PATH`. See [helper scripts](#helper-scripts).