Settings

Git server settings

Each git server that civet will interact with is configured with options in a python dictionary that resides in civet/settings.py

The variable INSTALLED_GITSERVERS is a list of these dictionaries.

Available options

• type[int]: Indicates what type of API to use. One of GITSERVER_GITHUB, GITSERVER_GITLAB, or GITSERVER_BITBUCKET
• api_url[str]: The base URL to access the API
  • For example: https://api.github.com
• html_url[str]: The base URL for providing links
  • For example: https://github.com
• hostname[str]: Hostname for the configuration. The hostname will be matched in the recipes.
  • For example, in a recipe: repository = git@github.com:idaholab/civet will match the hostname github.com
• secret_id[str]: The secret given by OAuth Apps
• client_id[str]: The client id given by OAuth Apps
• post_event_summary[bool]: Whether to post a PR comment with a summary of job statuses
  • This only happens when the event is complete (all the jobs that can run have run)
  • We typically have this turned off for GitHub but have it turned on for our internal GitLab. This was mostly for historical reasons as GitLab used to not have status updates like GitHub.
• post_job_status[bool]: Whether to post a PR comment when a job finishes
  • This isn't really used anywhere. It could probably be removed
• remote_update[bool]: flag used while testing. Prevents the update of comments and PR statuses.
  • It is very important to set this to True on the production server
• install_webhook[bool]: Determines if a webhook is installed when doing ./manage.py load_recipes --install-webhooks
  • We generally don't auto install webhooks anymore as we usually want to avoid the check because things very rarely change.
• remove_pr_label_prefix[list[str]]: Labels with this prefix will be removed when a PR branch is pushed to
  • These are labels that are on the git server and attached to a Pull Request
  • This currently only seems to be used on GitHub
• pr_wip_prefix[list[str]]: If a PR has a title that starts with one of these then it will be ignored.
  • This prevents testing of PRs that are really just up there for people to look at
• failed_but_allowed_label_name[str]: If set, this label will be added to a PR if there are failed but allowed tests for a commit.
  • Normally the CI status on the GitHub page would just show green and it is not obvious that some tests have failed.
  • This label will be removed automatically when new commits are pushed to the PR.
• recipe_label_activation[dict]: Labels for dynamic job activation.
  • The keys should correspond to activate_label in the recipes.
  • The values correspond to the files that have changed.
• recipe_label_activation_additive[str]: Labels in this list match the keys in recipe_label_activation.
  • The difference being that if all the changed files in the PR match one of these labels, all the regular tests will run in addition to the recipes that match this label.
  • If it is not in this list then only recipes matching the label (and their dependencies) are run.
  • The way these are done really needs to be rethought. It is currently not flexible enough to handle all the desired cases.
    • For example, MOOSE documentation.
      • When only documentation changes on a PR then we only run documentation testing
      • When something in python/MooseDocs changes we want to test application documentation to make sure nothing broke
      • If only something in python/MooseDocs gets changed, ideally we would only want to test MOOSE documentation and application documentation but currently everything gets tested.
• ssl_cert[bool]: Setting this to false will cause SSL cert verification to be disabled when communicating with the GitLab server.
  • Setting it to a filename of the cert of the server will enable verification with the added bonus of reducing the number of log messages.
• authorized_users[list[str]]: These users can see job client information.
  • Can contain groups, users, and teams.
  • Example: ["idaholab/MOOSE Team"]
• icon_class[str]: This is the CSS class that will be used when showing the server icon.
  • GitHub example: fa fa-github fa-lg

Repository settings

There are also settings that are specific to a particular repository. The repository_settings key holds a dictionary of settings with the key being the repository (for example idaholab/moose) and the value being a dictionary of settings.

• failed_but_allowed_label_name: Overrides the global parameter above
• recipe_label_activation: Overrides the global parameter above
• recipe_label_activation_additive: Overrides the global parameter above
• auto_merge_require_review[bool]: Require an approved review before doing an auto merge
• auto_merge_label[str]: Label that indicates that a PR should try to be auto merged
• auto_merge_enabled[bool]: Whether auto merge is enabled
• badges[list[dict]]: A list of additional boxes that show up on a repository summary.
  • keys in the dict are recipe and name.
    • recipe: The job status of the given recipe will be used as the status
    • name: Name to show up on the dashboard
  • Shows up after the branch statuses for the repository
  • See the badge feature description
  • Example for the deprecated badge on MOOSE

        {"recipe": "recipes/moosebuild/moose/Test_deprecated.cfg", "name": "deprecated",}

• branch_settings[dict]: A dictionary of settings for a specific repository branch
  • key is branch name.
  • Available options:
    • auto_cancel_push_events_except_current[bool]: This enables the auto cancel feature.
    • auto_uncancel_previous_event[bool]: Enables un-canceling of a previous event if a job on the current event fails