# 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 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 Advanced Search=?advanced-search 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 base URL for the reviews manifest files. If this option is specified, # then the review information is displayed on the package version details # page. # # The complete URL is formed by adding the following path to the base: # # <project>/<package>/<version>/reviews.manifest # # Note that no separator is added between the base and this path. # # reviews-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 /home/brep/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 /home/brep/submit-temp # The maximum size of the submission data accepted. Note that currently the # entire submission request is read into memory. Default is 10M. # # 100M. # submit-max-size 104857600 # 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 /home/brep/install/share/brep/www/submit.xhtml # 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 /home/brep/install/bin/brep-submit-pub # 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 --user submit-handler-argument brep submit-handler-argument --result-url submit-handler-argument http://unknown submit-handler-argument /home/brep/install/bin/brep-load submit-handler-argument --db-name=brep_submit_package submit-handler-argument /var/brep/bpkg/pkg # 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 120 # 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