app.cfg.example

# This file is part of the EESSI build-and-deploy bot,
# see https://github.com/EESSI/eessi-bot-software-layer
#
# The bot helps with requests to add software installations to the
# EESSI software layer, see https://github.com/EESSI/software-layer
#
# author: Kenneth Hoste (@boegel)
# author: Bob Droege (@bedroge)
# author: Hafsa Naeem (@hafsa-naeem)
# author: Jonas Qvigstad (@jonas-lq)
# author: Pedro Santos Neves (@Neves-P)
# author: Thomas Roeblitz (@trz42)
# author: Sam Moors (@smoors)
#
# license: GPLv2
#

# Also see documentation at https://github.com/EESSI/eessi-bot-software-layer/blob/main/README.md#step5.5

[git]
# Name of the Git hosting platform (supported values are 'github' and 'gitlab')
hosting_platform = github

[github]
# API timeout, time limit for requests to GitHub's REST API
api_timeout = 10

# replace '123456' with the ID of your GitHub App; see https://github.com/settings/apps
app_id = 123456

# a short (!) name for your app instance that can be used for example
#   when adding/updating a comment to a PR
# (!) a short yet descriptive name is preferred because it appears in
#   comments to the PR
# for example, the name could include the name of the cluster the bot
#   runs on and the username which runs the bot
# NOTE avoid putting an actual username here as it will be visible on
#      potentially publicly accessible GitHub pages.
app_name = MY-bot

# replace '12345678' with the ID of the installation of your GitHub App
#   (can be derived by creating an event and then checking for the list
#   of sent events and its payload either via the Smee channel's web page
#   or via the Advanced section of your GitHub App on github.com)
installation_id = 12345678

# path to the private key that was generated when the GitHub App was registered
private_key = PATH_TO_PRIVATE_KEY

[gitlab]
# NOTE: Access token required for GitLab:
# https://docs.gitlab.com/user/project/settings/project_access_tokens/#bot-users-for-projects
# Must be stored in environment variable 'GITLAB_PROJECT_ACCESS_TOKEN'.

# API timeout, time limit for requests to GitLab's REST API
api_timeout = 10

# Name used to refer to your bot instance - see comment for github.app_name config
bot_name = MY-bot

# The base URL of your GitLab instance
instance_url = https://gitlab.com


[bot_control]
# which GH/GL accounts have the permission to send commands to the bot
# if value is left/empty everyone can send commands
# value can be a space delimited list of GH/GL accounts
#
# NOTE, be careful to not list the bot's name (GH app name or GL bot account
#   name) or it may consider comments created/updated by itself as a bot
#   command and thus enter an endless loop.
command_permission =

# format of the response when processing bot commands. NOTE, make sure the
# placeholders {app_name}, {comment_response} and {comment_result} are included.
command_response_fmt =
    <details><summary>Updates by the bot instance <code>{app_name}</code>
    <em>(click for details)</em></summary>

    {comment_response}
    {comment_result}
    </details>

# chattiness level of the bot in terms of writing comments into PRs
# (incognito - no comments, minimal - respond with single comment on bot
# commands `help`, `show_config`, `status` and `build` and update job
# progress, basic - minimal + report failures, or chatty - comments on
# any event being processed)
chatlevel = basic

[buildenv]
# name of the job script that is submitted by the event handler (e.g.,
# used for building an EESSI stack)
build_job_script = PATH_TO_EESSI_BOT/scripts/bot-build.slurm

# path to a directory on a shared filesystem that can be used for sharing
# data across build jobs (for example source tarballs used by EasyBuild)
shared_fs_path = PATH_TO_SHARED_DIRECTORY

# Path (directory) to which build logs for (only) failing builds should be copied by bot/build.sh script
build_logs_dir = PATH_TO_BUILD_LOGS_DIR

#The container_cachedir may be used to reuse downloaded container image files
#across jobs. Thus, jobs can more quickly launch containers.
container_cachedir = PATH_TO_SHARED_DIRECTORY

# it may happen that we need to customize some CVMFS configuration
#   the value of cvmfs_customizations is a dictionary which maps a file
#   name to an entry that needs to be added to that file
# cvmfs_customizations = { "/etc/cvmfs/default.local": "CVMFS_HTTP_PROXY=\"http://PROXY_DNS_NAME:3128|http://PROXY_IP_ADDRESS:3128\"" }

# if compute nodes have no internet connection, we need to set http(s)_proxy
#   or commands such as pip3 cannot download software from package repositories
#   for example, the temporary EasyBuild is installed via pip3 first
# http_proxy = http://PROXY_DNS:3128/
# https_proxy = http://PROXY_DNS:3128/

# Used to give all jobs of a bot instance the same name. Can be used to allow
# multiple bot instances running on the same Slurm cluster.
job_name = prod

# The job_delay_begin_factor setting defines how many times the poll_interval a
# job's begin (EligibleTime) from now should be delayed if the handover protocol
# is set to `delayed_begin` (see setting `job_handover_protocol`). That is, if
# the job_delay_begin_factor is set to five (5) the delay time is calculated as
# 5 * poll_interval. The event manager would use 2 as the default factor when
# submitting jobs.
job_delay_begin_factor = 2

# The job_handover_protocol setting defines which method is used to handover a
# job from the event handler to the job manager. Values are
#  - hold_release (job is submitted with '--hold', job manager removes the hold
#    with 'scontrol release')
#  - delayed_begin (job is submitted with '--begin=now+(5 * poll_interval)' and
#    any '--hold' is removed from the submission parameters); this is useful if the
#    bot account cannot run 'scontrol release' to remove the hold of the job;
#    also, the status update in the PR comment of the job is extended by noting
#    the 'EligibleTime'
job_handover_protocol = hold_release

# directory under which the bot prepares directories per job
#   structure created is as follows: YYYY.MM/pr_PR_NUMBER/event_EVENT_ID/run_RUN_NUMBER/OS+SUBDIR
jobs_base_dir = $HOME/jobs

# configure environment
#   list of comma-separated modules to be loaded by build_job_script
#   useful/needed if some tool is not provided as system-wide package
#   (read by bot and handed over to build_job_script via parameter
#   --load-modules)
load_modules =

# PATH to temporary directory on build node ... ends up being used for
#     for example, EESSI_TMPDIR --> /tmp/$USER/EESSI
#   escaping variables with '\' delays expansion to the start of the
#     build_job_script; this can be used for referencing environment
#     variables that are only set inside a Slurm job
local_tmp = /tmp/$USER/EESSI

# PATH to a script that - if it exists - is sourced in the build job
#     before any 'bot/*' script is run. This allows to customize the
#     build environment due to specifics of the build site/cluster.
#     Note, such customizations could also be performed by putting them
#     into a module file and using the setting 'load_modules' (see above).
#     However, the setting 'site_config_script' provides a low threshold
#     for achieving this, too.
site_config_script = /path/to/script/if/any

# parameters to be added to all job submissions
# NOTE do not quote parameter string. Quotes are retained when reading in config and
#      then the whole 'string' is recognised as a single parameter.
# NOTE 2 '--get-user-env' may be needed on systems where the job's environment needs
#        to be initialised as if it is for a login shell.
slurm_params = --hold

# full path to the job submission command
submit_command = /usr/bin/sbatch

# full path to the job cancellation command
cancel_command = /usr/bin/scancel

# defines which GitHub accounts have the permission to trigger
# build jobs, i.e., for which accounts the bot acts on `bot: build ...`
# commands. If the value is left empty, everyone can trigger build jobs.
build_permission = -NOT_ALLOWED_GH_ACCOUNT_NAME-

# template for comment when user who set a label has no permission to trigger build jobs
no_build_permission_comment = GH account `{build_labeler}` is not authorized to trigger or cancel build jobs.

# whether or not to allow updating the submit options via custom module det_submit_opts
# Should only be enabled (true) with care because this will result in code from the target
# repository being executed by the event handler process, that is, not in a compute job.
allow_update_submit_opts = false

# defines which name-value pairs (environment variables) are allowed to be
# exported into the build environment via 'exportvariable' (or 'job_env_vars') filters
# The bot build script makes use of the variable 'SKIP_TESTS' to determine if
# ReFrame tests shall be skipped or not. Default value is 'no'. If the value is
# 'yes' and the exportvariable filter is added to a bot build command
# ('export:SKIP_TESTS=yes'), ReFrame tests are skipped.
# NOTE, the setting is optional and commented by default. If you want to enable
# this feature ('exportvariable' filters), uncomment the line below and define
# meaningful key-value pair(s). For example, to enable the use of
# 'exportvariable:SKIP_TESTS=yes' as a filter, the key-value pair would be
# "SKIP_TESTS=yes".
# allowed_exportvars = ["NAME1=value_1a", "NAME1=value_1b", "NAME2=value_2"]
#
# It's safe to use the following line as default setting:
allowed_exportvars = []

# defines which key-value pairs are allowed to be exported into the build
# environment via 'job_env_vars' (or 'exportvariable') filters. Each entry is a
# dict with 'key' and 'value' keys whose values are regular expressions. An
# argument 'KEY=VALUE' is accepted if its key matches one entry's 'key' regex
# AND its value matches that same entry's 'value' regex; otherwise it is
# rejected and no jobs are prepared.
# Patterns are matched using Python's 're' module (re.fullmatch), so the patterns
# are Python regular expressions.
# If 'allowed_job_env_vars' is not defined, the bot falls back to the existing
# 'allowed_exportvars' setting (see above), converting each exact 'KEY=VALUE'
# string into an equivalent regex pattern. This preserves backward
# compatibility for existing deployments.
# NOTE, the setting is optional. If you want to enable this feature, uncomment
# the line below and define meaningful pattern(s). For example:
# allowed_job_env_vars = [{"key": "SKIP_TESTS", "value": "yes|no"}, {"key": "DEBUG_.*", "value": "true|false"}]
# More advanced examples:
#   - allow any value for EB_ARGS (e.g. EB_ARGS=--installpath=/tmp/$USER/pr12345):
#     allowed_job_env_vars = [{"key": "EB_ARGS", "value": ".*"}]
#   - allow a specific set of install paths:
#     allowed_job_env_vars = [{"key": "EB_ARGS", "value": "--installpath=/tmp/.*"}]
#   - allow unsetting a variable (empty value):
#     allowed_job_env_vars = [{"key": "FOO", "value": ""}]
#
# It's safe to use the following line as default setting:
allowed_job_env_vars = []

# SECURITY NOTE: as a defence-in-depth measure, the bot sanitizes all job_env_vars
# and submit_args values and rejects any argument that contains shell
# metacharacters. For job_env_vars, keys and values are validated separately
# against the character allow-lists defined by tasks.build.JOB_ENV_VARS_KEY_RE
# and tasks.build.JOB_ENV_VARS_VALUE_RE. For submit_args, the character
# allow-list defined by tasks.build.SUBMIT_ARG_RE is used. This prevents shell
# injection even if a pattern above is overly permissive (e.g. value '.*').
# Additionally, pattern entries that are not well-formed dicts with string
# 'key'/'value' values are silently dropped at configuration read time.

# defines which options are allowed to be passed to the job submission command
# (e.g. sbatch) via submit_args filters. Each entry is a dict with a 'value'
# key whose value is a regular expression. An argument is accepted if it
# matches one entry's 'value' regex; otherwise it is rejected and no jobs are
# prepared. Unlike job_env_vars, these options are NOT exported into the build
# environment -- they are appended to the sbatch command line only.
# Patterns are matched using Python's 're' module (re.fullmatch), so the patterns
# are Python regular expressions.
# NOTE on argument ordering: the full submit command is constructed as:
#   <submit_command> <slurm_params> <time_limit> <slurm_opts> [--job-name=...] <submit_args> <script>
# where <slurm_params> is the global setting from [buildenv], <slurm_opts> comes
# from the node type's 'slurm_params' in the node_map, and <submit_args> are the
# user-supplied submit_args. Because submit_args are placed AFTER slurm_params and
# slurm_opts, they can override values set by the site configuration (e.g.
# partition, time limit, memory). Site operators should be aware of this when
# defining allowed_submit_args patterns.
# NOTE, the setting is optional. If you want to enable this feature, uncomment
# the line below and define meaningful pattern(s). For example:
# allowed_submit_args = [{"value": "--time=.*"}, {"value": "--partition=.*"}]
# More advanced examples:
#   - allow a specific time format only:
#     allowed_submit_args = [{"value": "--time=[0-9]{2}:[0-9]{2}:[0-9]{2}"}]
#   - allow multiple options with one pattern:
#     allowed_submit_args = [{"value": "--(time|partition|mem)=.*"}]
#
# It's safe to use the following line as default setting:
allowed_submit_args = []

# mechanisn to use to clone Git repository
# 'https' to clone via HTTPS (git clone https://github.com/<owner>/<repo>)
# In case of using 'ssh', one may need additional steps to ensure that the bot
# uses the right ssh key and does not ask for a passphrase (if the key used is
# protected with one). Here are a few things to consider:
#  - if the ssh key to be used does not have a standard name (e.g., 'id_rsa'),
#    add the following entry to '~/.ssh/config' in the bot's account
#
#    Host github.com
#      User git
#      IdentityFile ~/.ssh/NAME_OF_PRIVATE_KEY_FILE
#
#  - if the key is protected by a passphrase (**highly recommended**), run an
#    SSH agent and add the key to it (with the following two commands)
#
#    eval $(ssh-agent -s)
#    ssh-add ~/.ssh/NAME_OF_PRIVATE_KEY_FILE

clone_git_repo_via = https

[deploycfg]
# script for uploading built software packages
artefact_upload_script = PATH_TO_EESSI_BOT/scripts/eessi-upload-to-staging

# URL to S3/minio bucket
#   if attribute is set, bucket_base will be constructed as follows
#     bucket_base=${endpoint_url}/${bucket_name}
#   otherwise, bucket_base will be constructed as follows
#     bucket_base=https://${bucket_name}.s3.amazonaws.com
# - The former variant is used for non AWS S3 services, eg, minio, or when
#   the bucket name is not provided in the hostname (see latter case).
# - The latter variant is used for AWS S3 services.
endpoint_url = URL_TO_S3_SERVER

# bucket name:
# the value can be a simple string, to always use same bucket regardless of
# the target repo, or can be a mapping of a target repo id (see also
# setting repo_target_map) to a bucket name as in
# bucket_name = {
#   "eessi.io-2023.06-software": "eessi.io-staging-2023.06",
#   "eessi.io-2025.06-software": "software.eessi.io-2023.06"
# }
bucket_name = eessi-staging

# upload policy: defines what policy is used for uploading built artefacts
#                to an S3 bucket
# 'all' ..: upload all artefacts (mulitple uploads of the same artefact possible)
# 'latest': for each build target (eessi-VERSION-{software,init,compat}-OS-ARCH)
#           only upload the latest built artefact
# 'once'  : only once upload any built artefact for the build target
# 'none'  : do not upload any built artefacts
upload_policy = once

# which GH account has the permission to trigger the deployment by setting
# the label 'bot:deploy' (apparently this cannot be restricted on GitHub)
# if value is left/empty _no one_ can trigger the deployment
# value can be a space delimited list of GH accounts
deploy_permission =

# template for comment when user who set a label has no permission to trigger deploying artefacts
no_deploy_permission_comment = Label `bot:deploy` has been set by user `{deploy_labeler}`, but this person does not have permission to trigger deployments

# settings for where (directory) in the S3 bucket to store the metadata file and
# the artefact
# - Can be a string value to always use the same 'prefix' regardless of the target
#   CVMFS repository, or can be a mapping of a target repository id (see also
#   repo_target_map) to a prefix.
# - The prefix itself can use some (environment) variables that are set within
#   the script. Currently those are:
#   * 'github_repository' (which would be expanded to the full name of the GitHub
#     repository, e.g., 'EESSI/software-layer'),
#   * 'legacy_aws_path' (which expands to the legacy/old prefix being used for
#     storing artefacts/metadata files) and
#   * 'pull_request_number' (which would be expanded to the number of the pull
#     request from which the artefact originates).
# - The list of supported variables can be shown by running
#   `scripts/eessi-upload-to-staging --list-variables`.
# - Examples:
#   metadata_prefix = {"eessi.io-2023.06": "new/${github_repository}/${pull_request_number}"}
#   artefact_prefix = {"eessi-pilot-2023.06": "", "eessi.io-2023.06": "new/${github_repository}/${pull_request_number}"}
# If left empty, the old/legacy prefix is being used.
metadata_prefix =
artefact_prefix =

# settings for signing artefacts with JSON-like format
#
#    "REPO_ID": { "script": "PATH_TO_SIGN_SCRIPT", "key": "PATH_TO_KEY_FILE", "container_runtime": "PATH_TO_CONTAINER_RUNTIME" }
#
#  REPO_ID is the repository ID. Repository IDs are defined in a file `repos.cfg`
#  and _must_ match it (see setting `repos_cfg_dir`).
#
#  If PATH_TO_SIGN_SCRIPT is a relative path, the script must reside in the
#  checked out pull request of the target repository (e.g.,
#  EESSI/software-layer).
#
#  The bot calls the script with the two arguments:
#   1. private key (as provided by the attribute 'key')
#   2. path to the file to be signed (the upload script will determine that)
#
# NOTE (on "container_runtime"), signing requires a recent installation of OpenSSH
#   (8.2 or newer). If the frontend where the event handler runs does not have that
#   version installed, you can specify a container runtime via the 'container_runtime'
#   attribute below. Currently, only Singularity or Apptainer are supported.
# NOTE (on the private key file), make sure the file permissions are restricted to `0600`
#   (only readable+writable by the file owner) or the signing will likely fail.
# NOTE (on the JSON-like format), make sure commas are only used for separating elements
#   or parsing/loading the json will likely fail. Also, the whole value should start
#   at a new line and be indented as shown below.
# NOTE (on double quotes), as shown in the example below, use double quotes for all keys
#   and values.
signing =
    {
        "eessi.io-2023.06-software": {
            "script": "PATH_TO_SIGN_SCRIPT",
            "key": "PATH_TO_EESSI_BOT/config/user-site-system.key",
            "container_runtime": "PATH_TO_CONTAINER_RUNTIME"
        }
    }


[architecturetargets]
# arch_target_map has been replaced by node_type_map
# arch_target_map = {
# }

# Each entry in the node_type_map dictionary describes a build node type. The key is a (descriptive) name for this build node, and its value is a dictionary containing the following build node properties as key-value pairs:
  - os: its operating system (os)
  - cpu_subdir: its CPU architecture
  - slurm_params: the SLURM parameters that need to be passed to submit jobs to it
  - repo_targets: supported repository targets for this node type
  - accel (optional): which accelerators this node has
# All are strings, except repo_targets, which is a list of strings.
# Note that the Slurm parameters should typically be chosen such that a single type of node (with one specific type of
# CPU and one specific type of GPU) should be allocated.
# Below is an example configuration for a system that contains 4 types of nodes: zen2 CPU nodes, zen4 CPU nodes,
# GPU nodes with an icelake CPU and A100 GPU, GPU nodes with a zen4 CPU and an H100 GPU.
# The 'on:' argument to the bot build command determines which node type will be allocated for the build job,
# e.g. 'bot:build on:arch=zen4,accel=nvidia/cc90 for:...' will match the gpu_h100 node type below.
# If no 'on:' argument is passed to the build command, the 'for:' argument is used instead,
# e.g. 'bot:build for:arch=icelake,accel=nvidia/cc80' will match the gpu_a100 node type below.
node_type_map = {
    "cpu_zen2": {
        "os": "linux",
        "cpu_subdir": "x86_64/amd/zen2",
        "slurm_params": "-p rome --nodes 1 --ntasks-per-node 16 --cpus-per-task 1",
        "repo_targets": ["eessi.io-2023.06-compat","eessi.io-2023.06-software"]
    },
    "cpu_zen4": {
        "os": "linux",
        "cpu_subdir": "x86_64/amd/zen4",
        "accel": "None",
        "slurm_params": "-p genoa --nodes 1 --ntasks-per-node 24 --cpus-per-task 1",
        "repo_targets": ["eessi.io-2023.06-compat","eessi.io-2023.06-software"]
    },
    "gpu_a100": {
        "os": "linux",
        "cpu_subdir": "x86_64/intel/icelake",
        "accel": "nvidia/cc80",
        "slurm_params": "-p gpu_a100 --nodes 1 --tasks-per-node 18 --cpus-per-task 1 --gpus-per-node 1",
        "repo_targets": ["eessi.io-2023.06-compat","eessi.io-2023.06-software"]
    },
    "gpu_h100": {
        "os": "linux",
        "cpu_subdir": "x86_64/amd/zen4",
        "accel": "nvidia/cc90",
        "slurm_params": "-p gpu_h100 --nodes 1 --tasks-per-node 16 --cpus-per-task 1 --gpus-per-node 1",
        "repo_targets": ["eessi.io-2023.06-compat","eessi.io-2023.06-software"]
    }}

[repo_targets]

# No longer used, repo targets are now specified per node type in the node_type_map
# repo_target_map = {
#     "linux/x86_64/amd/zen2" : ["eessi.io-2023.06-software","eessi.io-2025.06-software"] }

# points to definition of repositories (default repository defined by build container)
repos_cfg_dir = PATH_TO_SHARED_DIRECTORY/repos


# configuration for event handler which receives events from a GitHub repository.
[event_handler]
# path to the log file to log messages for event handler
log_path = /path/to/eessi_bot_event_handler.log


[job_manager]
# path to the log file to log messages for job manager
log_path = /path/to/eessi_bot_job_manager.log

# directory where job manager stores information about jobs to be tracked
#   e.g. as symbolic link JOBID -> directory to job
job_ids_dir = $HOME/jobs/ids

# full path to the job status checking command
poll_command = /usr/bin/squeue

# polling interval in seconds
poll_interval = 60

# full path to the command for manipulating existing jobs
# It is also possible to add placeholder values to the scontrol_command.
# An example where this may be useful is in a setup where multiple clusters are managed by the same SLURM instance, 
# and the `scontrol_command` for that instance needs to get the correct cluster name passed. 
# This can be achieved by defining `scontrol_command = /usr/bin/scontrol --clusters=%%(cluster)s`. 
# Valid placeholder names are currently: `jobid`, `cluster`, `partition`, `state`, and `reason`.
scontrol_command = /usr/bin/scontrol


# Note 1. The value of the setting 'initial_comment' in section
#         '[submitted_job_comments]' should not be changed because the bot
#         uses regular expression pattern to identify a comment with this
#         format.
# Note 2. Any name inside curly brackets is replaced by the bot with
#         corresponding data. If the name is changed or the curly brackets
#         are removed, the output (in PR comments) will lack important
#         information.
[submitted_job_comments]
# awaits_release is no longer used since bot release v0.7.0
# awaits_release = job id `{job_id}` awaits release by job manager
awaits_release_delayed_begin_msg = job id `{job_id}` will be eligible to start in about {delay_seconds} seconds
awaits_release_hold_release_msg = job id `{job_id}` awaits release by job manager
new_job_instance_repo = New job on instance `{app_name}` for repository `{repo_id}`
build_on_arch = Building on: `{on_arch}`{on_accelerator}
build_for_arch = Building for: `{for_arch}`{for_accelerator}
jobdir = Job dir: `{symlink}`
# commit_sha format for the 5th line in the initial PR comment; `{commit_sha}` is replaced with the commit SHA
# from the cloned repository (i.e., the base branch HEAD at the time the job starts).
commit_sha = Commit SHA: {commit_sha}
with_accelerator = &nbsp;and accelerator `{accelerator}`
# initial_comment = New job on instance `{app_name}` for repository `{repo_id}`\nBuilding on: `{on_arch}`{on_accelerator}\nBuilding for: `{for_arch}`{for_accelerator}\nJob dir: `{symlink}`  # no longer used


[new_job_comments]
awaits_launch = job awaits launch by Slurm scheduler{extra_info} 


[running_job_comments]
running_job = job `{job_id}` is running


[finished_job_comments]
job_result_unknown_fmt = <details><summary>:shrug: UNKNOWN _(click triangle for detailed information)_</summary><ul><li>Job results file `{filename}` does not exist in job directory, or parsing it failed.</li><li>No artefacts were found/reported.</li></ul></details>
job_test_unknown_fmt = <details><summary>:shrug: UNKNOWN _(click triangle for detailed information)_</summary><ul><li>Job test file `{filename}` does not exist in job directory, or parsing it failed.</li></ul></details>


[download_pr_comments]
make_dirs_failure = Unable to create the target directory.
make_dirs_tip = _Tip: This could be a problem with write permissions or disk space._
git_clone_failure = Unable to clone the target repository. 
git_clone_tip = _Tip: This could be a connection failure. Try again and if the issue remains check if the address is correct_.
git_checkout_failure = Unable to checkout to the correct branch.
git_checkout_tip = _Tip: Ensure that the branch name is correct and the target branch is available._
git_apply_failure = Unable to download or merge changes between the source branch and the destination branch.
git_apply_tip = _Tip: This can usually be resolved by syncing your branch and resolving any merge conflicts._
pr_diff_failure = Unable to obtain PR diff.
pr_diff_tip = _Tip: This could be a problem with HTTPS/SSH access to the repository._


[clean_up]
trash_bin_dir = $HOME/trash_bin
moved_job_dirs_comment = PR merged! Moved `{job_dirs}` to `{trash_bin_dir}`