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

[github]
# 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


[bot_control]
# which GH 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 accounts
#
# NOTE, be careful to not list the bot's name (GH app 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>


[buildenv]
# name of the job script used for building an EESSI stack
build_job_script = PATH_TO_EESSI_BOT/scripts/bot-build.slurm

# path to directory on 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/

# 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

# 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

# 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

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

# template for comment when user who set a label has no permission to trigger build jobs
no_build_permission_comment = Label `bot:build` has been set by user `{build_labeler}`, but this person does not have permission to trigger builds

# whether or not to allow updating the submit options via custom module det_submit_opts
allow_update_submit_opts = false

# defines which name-value pairs (environment variables) are allowed to be
# exported into the build environment via 'exportvariable' 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"]


[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:
# can be a string value, to always use same bucket regardless of target repo,
# or can be a mapping of target repo id (see also repo_target_map) to bucket name
# like: bucket_name = {"eessi-pilot-2023.06": "eessi-staging-pilot-2023.06", "eessi.io-2023.06": "software.eessi.io-2023.06"}
bucket_name = eessi-staging

# 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 }
#  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 key), make sure the file permissions are restricted to `0600` (only
#   readable+writable by the file owner, or the signing will likely fail.
# Note (on json format), make sure no trailing commas are used after any 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.
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
        }
    }
# 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 everyone 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 =


[architecturetargets]
# defines both for which architectures the bot will build
#   and what submission parameters shall be used
arch_target_map = { "linux/x86_64/generic" : "--constraint shape=c4.2xlarge", "linux/x86_64/amd/zen2": "--constraint shape=c5a.2xlarge" }


[repo_targets]
# defines for which repository a arch_target should be build for
#
# EESSI/2021.12 and NESSI/2022.11
repo_target_map = { "linux/x86_64/amd/zen2" : ["eessi-2021.12","nessi.no-2022.11"] }

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


# 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
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 = 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
initial_comment = New job on instance `{app_name}` for CPU micro-architecture `{arch_name}`{accelerator_spec} for repository `{repo_id}` in job dir `{symlink}`
with_accelerator = &nbsp;and accelerator `{accelerator}`


[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]
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._
curl_failure = Unable to download the `.diff` file.
curl_tip = _Tip: This could be a connection failure. Try again and if the issue remains check if the address is correct_
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._

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