# Configuration file for the brep module (note: this is not an apache2 .conf
# file but it can be converted to one by prefixing all the options with
# brep-). See brep(1) for detailed description of each configuration option.
# Commented out options indicate their default values.
#
# Besides being parsed by the brep module, this file may also be parsed by
# brep utilities that are normally only interested in the subset of the
# options. To simplify skipping of unrecognized, this file must always have an
# option name and its value on the same line.
#

# Package search page title. It is placed inside XHTML5 <title> element.
#
# search-title Packages


# Package search page description. If specified, it is displayed before the
# search form on the first page only. The value is treated as an XHTML5
# fragment.
#
# search-description ""


# Web page logo. It is displayed in the page header aligned to the left edge.
# The value is treated as an XHTML5 fragment.
#
# logo ""


# Web page menu. Each entry is displayed in the page header in the order
# specified and aligned to the right edge. A link target that starts with '/'
# or contains ':' is used as is. Otherwise, it is prefixed with the repository
# web interface root.
#
menu Packages=
# menu Builds=?builds
# menu Configs=?build-configs
# menu Submit=?submit
# menu CI=?ci
menu About=?about


# Number of packages per page.
#
# search-page-entries 20


# Number of pages in navigation (pager).
#
# search-pages 5


# Number of package description characters to display in brief pages.
#
# package-description 500


# Number of package changes characters to display in brief pages.
#
# package-changes 5000


# The package database connection configuration. By default, brep will try to
# connect to the local instance of PostgreSQL with the operating system-
# default mechanism (Unix-domain socket, etc) and use operating system
# (login) user name and the database called 'brep_package'. If the role name
# is not empty then the login user will be switched (with SET ROLE) to this
# user prior to executing any statements. If not specified, then 'brep' is
# used. See brep(1) for details.
#
# package-db-user
# package-db-role     brep
# package-db-password
# package-db-name     brep_package
# package-db-host
# package-db-port


# The maximum number of concurrent package database connections per web server
# process. If 0, then no limitation is applied.
#
# package-db-max-connections 5


# The maximum number of times to retry package database transactions in the
# face of recoverable failures (deadlock, loss of connection, etc).
#
# package-db-retry 10


# Build configuration file. If not specified (default), then the package
# building functionality will be disabled. If specified, then the build
# database must be configured (see next). Note: must be an absolute path.
#
# build-config


# Number of build configurations per page.
#
# build-config-page-entries 20


# Number of pages in navigation (pager).
#
# build-config-pages 5


# Directory containing build bot agent public keys. If specified, then brep
# will perform agent authentication and will reject build results from
# unauthenticated ones. If not specified, then build results are accepted from
# all agents (which will be a security risk if the brep instance is publicly
# accessible).
#
# The directory is expected to contain one PEM-encoded public key per file with
# the .pem extension. All other files and subdirectories are ignored. The brep
# instance needs to be restarted after adding new key files for the changes to
# take effect.
#
# build-bot-agent-keys


# Regular expressions in the /<regex>/<replacement>/ form for transforming the
# interactive build login information, for example, into the actual command
# that can be used by the user. The regular expressions are matched against
# the "<agent> <interactive-login>" string containing the respective task
# request manifest values. The first matching expression is used for the
# transformation. If no expression matches, then the task request is
# considered invalid, unless no expressions are specified. Repeat this option
# to specify multiple expressions.
#
# build-interactive-login


# Order in which packages are considered for build. The valid values are
# 'stable' and 'random'. If not specified, then 'stable' is assumed. Note that
# interactive builds are always preferred.
#
#build-package-order stable


# Number of builds per page.
#
# build-page-entries 20


# Number of pages in navigation (pager).
#
# build-pages 5


# Time to wait before considering a package for a forced rebuild. Must be
# specified in seconds. Default is 10 minutes.
#
# build-forced-rebuild-timeout 600


# Time to wait before considering a package for a soft rebuild (only to be
# performed if the build environment or any of the package dependencies have
# changed). Must be specified in seconds. The special zero value disables soft
# rebuilds. Default is 24 hours.
#
# build-soft-rebuild-timeout 86400


# Alternative package soft rebuild timeout to use instead of the soft rebuild
# timeout (see the build-soft-rebuild-timeout option for details) during the
# specified time interval. Must be specified in seconds. Default is the time
# interval length plus (build-soft-rebuild-timeout - 24h) if soft rebuild
# timeout is greater than 24 hours (thus the rebuild is only triggered within
# the last 24 hours of the build-soft-rebuild-timeout expiration).
#
# The alternative rebuild timeout can be used to "pull" the rebuild window to
# the specified time of day, for example, to optimize load and/or power
# consumption of the build infrastructure (off-work hours, solar, off-peak
# electricity tariffs, etc). A shorter than the time interval rebuild timeout
# can also be used to force continuous rebuilds, for example, to shake out
# flaky tests. Note also that if the alternative rebuild timeout is greater
# than the normal rebuild timeout, then this will result in slower rebuilds
# during the alternative time interval. In this case, if the build
# infrastructure is monitored for delayed package builds, then the alternative
# rebuild timeout should only be made slightly greater than the normal timeout
# (see brep-monitor(1) for details).
#
# The time interval boundaries must be specified as times of day (in the local
# timezone) in the <hours>:<minutes> form. If the stop time is less than the
# start time then the interval extends through midnight. The start and stop
# times must both be either specified or absent. If unspecified, then no
# alternative rebuild timeout will be used.
#
# build-alt-soft-rebuild-timeout
# build-alt-soft-rebuild-start
# build-alt-soft-rebuild-stop


# Time to wait before considering a package for a hard rebuild (to be
# performed unconditionally). Must be specified in seconds. The special zero
# value disables hard rebuilds. Default is 7 days.
#
# build-hard-rebuild-timeout 604800


# Alternative package hard rebuild timeout. The semantics is the same as for
# the build-alt-soft-rebuild-* options but for the build-hard-rebuild-timeout
# option.
#
# build-alt-hard-rebuild-timeout
# build-alt-hard-rebuild-start
# build-alt-hard-rebuild-stop


# Time to wait before assuming the 'queued' notifications are delivered for
# package CI requests submitted via third-party services (GitHub, etc). During
# this time a package is not considered for a build. Must be specified in
# seconds. Default is 30 seconds.
#
# build-queued-timeout 30


# The maximum size of the build task request manifest accepted. Note that the
# HTTP POST request body is cached to retry database transactions in the face
# of recoverable failures (deadlock, loss of connection, etc). Default is
# 100K.
#
# build-task-request-max-size 102400


# Time to wait before considering the expected task result lost. Must be
# specified in seconds. Default is 3 hours.
#
# build-result-timeout 10800


# The maximum size of the build result manifest accepted. Note that the HTTP
# POST request body is cached to retry database transactions in the face of
# recoverable failures (deadlock, loss of connection, etc). Default is 10M.
#
# build-result-request-max-size 10485760


# Enable or disable package build notification emails in the <name>=<mode>
# form. The valid <mode> values are 'none', 'latest', and 'all'. If 'all' is
# specified for a toolchain name, then emails are sent according to the
# build-*email package manifest values when all versions of a package are
# built with this toolchain. If 'latest' is specified, then for this toolchain
# name the emails are only sent for the latest version of a package. If 'none'
# is specified, then no emails are sent for this toolchain name. By default
# the 'latest' mode is assumed. Repeat this option to enable/disable emails
# for multiple toolchains.
#
# build-toolchain-email <toolchain-name>=latest|none|all


# The build database connection configuration. By default, brep will try to
# connect to the local instance of PostgreSQL with the operating system-default
# mechanism (Unix-domain socket, etc) and use operating system (login) user
# name and the database called 'brep_build'. If the role name is not empty
# then the login user will be switched (with SET ROLE) to this user prior
# to executing any statements. If not specified, then 'brep' is used. See
# brep(1) for details.
#
# build-db-user
# build-db-role     brep
# build-db-password
# build-db-name     brep_build
# build-db-host
# build-db-port


# The maximum number of concurrent build database connections per web server
# process. If 0, then no limitation is applied.
#
# build-db-max-connections 5


# The maximum number of times to retry build database transactions in the
# face of recoverable failures (deadlock, loss of connection, etc).
#
# build-db-retry 10


# The root directory where the uploaded binary distribution packages are
# saved to under the following directory hierarchy:
#
# [<tenant>/]<distribution>/<os-release>/<project>/<package>/<version>/<package-config>
#
# The package configuration directory symlinks that match these paths are
# mapped to web URLs based on the bindist-url value and displayed on the
# package version details page. If this option is specified, then bindist-url
# must be specified as well."
#
# bindist-root


# The root URL of the directory specified with the bindist-root option. This
# option must be specified if bindist-root is specified.
#
# bindist-url


# The openssl program to be used for crypto operations. You can also specify
# additional options that should be passed to the openssl program with
# openssl-option. If the openssl program is not explicitly specified, then brep
# will use openssl by default.
#
# openssl openssl


# Additional option to be passed to the openssl program (see openssl for
# details). Repeat this option to specify multiple openssl options.
#
# openssl-option


# Environment variable to be set (<name>=<value>) or unset (just <name>) for
# the openssl program (see openssl for details). Repeat this option to specify
# multiple openssl variables. Note that unspecified variables are inherited
# from the web server process.
#
# You need to at least set the RANDFILE environment variable to change the
# default location of the openssl program seed file and maybe also the
# OPENSSL_CONF variable if you would like to use a custom openssl configuration
# file.
#
# openssl-envvar RANDFILE=/home/brep/www-data-openssl.rnd
# openssl-envvar OPENSSL_CONF=/home/brep/www-data-openssl.cnf
#
# To create www-data-openssl.rnd with suitable permissions, run (as user brep):
#
# $ touch www-data-openssl.rnd
# $ setfacl -b -m g:www-data:rw www-data-openssl.rnd
#


# The directory to save final submission data to. If unspecified, the package
# submission functionality will be disabled. If specified, then submit-temp
# must be specified as well.
#
# Note that the directory path must be absolute and the directory itself must
# exist and have read, write, and execute permissions granted to the user that
# runs the web server.
#
# submit-data


# The directory to save temporary submission data to. Must be specified if the
# package submission functionality is enabled.
#
# Note that this directory must be on the same filesystem and satisfy the same
# requirements as submit-data. It is also the user's responsibility to clean
# it up after an unclean web server shutdown.
#
# submit-temp


# The maximum size of the submission data accepted. Note that currently the
# entire submission request is read into memory. Default is 10M.
#
# submit-max-size 10485760


# The package submission form fragment. If specified, then its contents are
# treated as an XHTML5 fragment that is inserted into the <body> element of
# the submission page. If unspecified, then no submission page will be
# displayed. Note that the file path must be absolute.
#
# submit-form


# The package submission email. If specified, the submission request and
# result manifests will be sent to this address.
#
# submit-email


# The handler program to be executed on package submission. The handler is
# executed as part of the HTTP request and is passed additional arguments that
# can be specified with submit-handler-argument followed by the absolute path
# to the submission directory. Note that the program path must be absolute.
#
# submit-handler


# Additional arguments to be passed to the submission handler program (see
# submit-handler for details). Repeat this option to specify multiple
# arguments.
#
# submit-handler-argument


# The handler program timeout in seconds. If specified and the handler does
# not exit in the alloted time, then it is killed and its termination is
# treated as abnormal.
#
# submit-handler-timeout


# The directory to save CI request data to. If unspecified, the package CI
# functionality will be disabled.
#
# Note that the directory path must be absolute and the directory itself must
# exist and have read, write, and execute permissions granted to the user that
# runs the web server.
#
# ci-data


# The package CI form fragment. If specified, then its contents are treated as
# an XHTML5 fragment that is inserted into the <body> element of the CI page.
# If unspecified, then no CI page will be displayed. Note that the file path
# must be absolute.
#
# ci-form


# The package CI email. If specified, the CI request and result manifests will
# be sent to this address.
#
# ci-email


# The handler program to be executed on CI request. The handler is executed as
# part of the HTTP request and is passed additional arguments that can be
# specified with ci-handler-argument followed by the absolute path to the CI
# request directory. Note that the program path must be absolute.
#
# ci-handler


# Additional arguments to be passed to the CI handler program (see ci-handler
# for details). Repeat this option to specify multiple arguments.
#
# ci-handler-argument


# The CI handler program timeout in seconds. If specified and the handler does
# not exit in the allotted time, then it is killed and its termination is
# treated as abnormal.
#
# ci-handler-timeout


# The directory to save upload data to for the specified upload type. If
# unspecified, the build artifacts upload functionality will be disabled for
# this type.
#
# Note that the directory path must be absolute and the directory itself must
# exist and have read, write, and execute permissions granted to the user that
# runs the web server.
#
# upload-data <type>=<dir>


# The maximum size of the upload data accepted for the specified upload type.
# Note that currently the entire upload request is read into memory. The
# default is 10M.
#
# upload-max-size <type>=10485760


# The build artifacts upload email. If specified, the upload request and
# result manifests will be sent to this address.
#
# upload-email <type>=<email>


# The handler program to be executed on build artifacts upload of the
# specified type. The handler is executed as part of the HTTP request and is
# passed additional arguments that can be specified with
# upload-handler-argument followed by the absolute path to the upload
# directory (upload-data). Note that the program path must be absolute.
#
# upload-handler <type>=<path>


# Additional arguments to be passed to the upload handler program for the
# specified upload type (see upload-handler for details). Repeat this option
# to specify multiple arguments.
#
# upload-handler-argument <type>=<arg>


# The upload handler program timeout in seconds for the specified upload type.
# If specified and the handler does not exit in the allotted time, then it is
# killed and its termination is treated as abnormal.
#
# upload-handler-timeout <type>=<seconds>


# Disable upload of the specified type for the specified toolchain name.
# Repeat this option to disable uploads for multiple toolchains.
#
# upload-toolchain-exclude <type>=<name>


# Disable upload of the specified type for packages from the repository with
# the specified canonical name. Repeat this option to disable uploads for
# multiple repositories.
#
# upload-repository-exclude <type>=<name>


# The default view to display for the global repository root. The value is one
# of the supported services (packages, builds, submit, ci, etc). Default is
# packages.
#
# root-global-view packages


# The default view to display for the tenant repository root. The value is one
# of the supported services (packages, builds, submit, ci, etc). Default is
# packages.
#
# root-tenant-view packages


# Name to call the tenant values on web pages. If not specified, then 'tenant'
# is used.
#
# tenant-name tenant


# Trace verbosity. Disabled by default.
#
# verbosity 0