diff options
| -rw-r--r-- | doc/manual.cli | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/manual.cli b/doc/manual.cli index bda4bc9..db157e6 100644 --- a/doc/manual.cli +++ b/doc/manual.cli @@ -24,7 +24,7 @@ The \c{bbot} architecture includes several layers for security and manageability. At the top we have a \c{bbot} running in the \i{controller} mode. The controller monitors various \i{build sources} for \i{build tasks}. For example, a controller may poll a \c{brep} instances for any new -packages to built as well as monitor a \c{git} repository for any new commits +packages to built as well as monitor a \cb{git} repository for any new commits to test. There can be several layers of controllers with \c{brep} being just a special kind. A machine running a \c{bbot} instance in the controller mode is called a \i{controller host}. @@ -74,7 +74,7 @@ worker, to its agent, to its controller, and so on. A controller that is the final destination of a build result uses email to notify interested parties of the outcome. For example, \c{brep} would send a notification to the package owner if the build failed. Similarly, a \c{bbot} controller that monitors a -\c{git} repository would send an email to a committer if their commit caused a +\cb{git} repository would send an email to a committer if their commit caused a build failure. The email would include a link (normally HTTP/HTTPS) to the build logs hosted by the controller. @@ -348,7 +348,7 @@ The package version to build. repository: <repository-url> \ -The \c{bpkg} repository that contains the package and its dependencies. +The \cb{pkg} repository that contains the package and its dependencies. \h2#arch-task-trust|\c{trust}| |