example.yml

#############################
# 1. Global configuration
#############################

global:
  # Set this to True to skip verification of server SSL certificates.  This might
  # be necessary if your Jira / Bitbucket server has an invalid or a custom
  # certificate.  Or as an alternative, see the README.md for how to trust custom
  # certificates.
  no_verify_ssl: False
  # Set this to True if you would like to send your config.yml file to Jellyfish.
  # We use this as a diagnostic tool for customer assistance.
  send_agent_config: True

#############################
# 2. Jira configuration
#############################

jira:
  # URL to Jira
  url: https://jira.yourcompany.com

  # GDPR mode: enable this if your Jira instance's API has User
  # endpoints modified in order to support GDPR.  This should be True
  # for Atlassian Cloud hosted Jira as of March 30, 2019.
  gdpr_active: False

  # The earliest date for pulling issues into Jellyfish (format: YYYY-MM-DD).
  # Most companies want at least a year's worth of issues pulled into Jellyfish.
  # You'll generally just need to set this once, at onboarding time, and then
  # not change it (regular, day-to-day runs of the agent will only pull issues
  # that have been created or updated since the last run).  Comment out or omit
  # to pull all issues into Jellyfish.
  earliest_issue_dt: 2023-01-01

  # The number of concurrent threads the agent will use for downloading issue data.
  # It's unusual, but some Jira instances can be overwhelmed by more than one or
  # two threads making concurrent requests to its API.  If your Jira instance is
  # underpowered, you may want to set this to a low value.  If omitted, defaults
  # to 10.
  issue_download_concurrent_threads: 10

  # The number of issues per page to request when we hit the Jira API.  Empirically,
  # Jira Cloud won't return more than 100 issues at a time even if we ask for more,
  # but Jira Server can do more; 250 is often a successful setting with Jira Server.
  # If omitted, defaults to 100.
  issue_batch_size: 100

  # Whether the agent should download issue worklogs.  If omitted, defaults to True.
  download_worklogs: True

  # Whether the agent should download sprints.  If omitted, defaults to True.
  download_sprints: True

  # When provided, we will recurively download all parents until we run out of parents
  # to download. WARNING: This may greatly increase Agent run time!
  recursively_download_parents: False

  #############################
  # Options for filtering projects. Only data for projects that meet ALL
  # these criteria will be used. For example, if you provide both
  # `include_projects` and `include_project_categories` only the subset
  # of named projects that are in the specified category will be
  # included.
  #############################

  # Only pull issues from specific projects; omit to pull issues from
  # all projects.
  #
  # Note: use Jira project keys, not names.
  include_projects:
    - PROJ1
    - PROJ2

  # Uncomment this to pull issues from all but specific projects. You
  # will generally want to use either this OR `include_projects`, but
  # not both.
  #
  # Note: use project keys, not names.
  # exclude_projects:
  #   - PROJ1

  # Uncomment to pull issues from specific project categories only.
  # include_project_categories:
  #   - Engineering

  # Uncomment this to pull issues from all but specific project categories.
  # exclude_project_categories:
  #   - Support

  #############################
  # Options for filtering issues.  This filter is applied in addition
  # to any project-level filters above, to control which issues are
  # pulled for the given projects.
  #############################

  # Uncomment this to pull only issues matching a specific JQL
  # filter. Use this if you need more fine-grained control over pulling
  # just a subset of issues within a project.
  # issue_jql: 'text ~ pattern and issuetype != "Secret Type"'

  #############################
  # Options for filtering fields.  Use these if you need fine-grained control
  # over exactly which fields are pulled for each issue.  This can be useful
  # if some of your fields contain sensitive data that you don't want to
  # send to Jellyfish
  #############################

  # Uncomment this to pull all but specific fields on issues.
  # exclude_fields:
  #   - description
  #   - comment


  # if your Jira Users include customer records, you may wish to filter 
  # the users sent to Jellyfish by enumerating a set of required email domains
  #
  # required_email_domains:
  #   - jellyfish.co

  # it's possible for a user to have no email.  if we need to restrict users
  # by email domain, should null-email users be included?  uncomment this 
  # if they shouldn't:
  #
  # is_email_required: True

  # This is a special run mode that allows you to skip saving your JIRA data
  # locally, and instead continuously submit it via S3. This run mode is good
  # if you plan to upload a VERY large amount of data (like an initial upload
  # for a massive company). Please contact your Jellyfish representative to see
  # if this run configuration is right for you. In general, this flag should NOT
  # be included, or it should be set as False
  #
  # skip_saving_data_locally: True

#############################
# 3. Git configuration
#############################

# You can configure the agent to pull from a single Git instance or multiple Git
# instances.
#   - If you're pulling from a single Git instance, configure the "git"
#     object as a SINGLE OBJECT as per the example below.
#   - If you're pulling from multiple Git instances, configure the "git"
#     object as a LIST OF OBJECTS as per the example below.  For this
#     configuration, note that the instance_slug and creds_envvar_prefix
#     are additional required fields.

######################################
# 3a. Single instance config example
######################################
git:
  # Supported providers are `bitbucket_server`, `bitbucket_cloud`,
  # `gitlab`, `github`, and 'ado'.
  provider: bitbucket_server

  # URL to Bitbucket Server, Bitbucket Cloud, GitLab, GitHub, or ADO.
  # For Bitbucket Cloud, this should be https://api.bitbucket.org
  # For GitHub Cloud, this should be https://api.github.com
  # For Azure Devops (ado), this should be https://dev.azure.com
  # For GitHub Enterprise, this should be https://github.yourcompany.com/api/v3 (note lack of trailing slash).
  # Otherwise, use the URL to your local git server.
  url: https://bitbucket.yourcompany.com

  # Only pull from specific projects / organizations / groups.
  # Bitbucket Server: use project keys, not names. Comment this out to pull from all projects.
  # Bitbucket Cloud (required): use your workspace name, as it appears in your Bitbucket URLs
  # GitHub (required): use your organization name, as it appears in your GitHub URLs (e.g.: MyOrg)
  # GitLab (required): use the top-level GitLab "Group ID" (e.g.: 123)
  # Azure Devops (required): use your organization name, which contains your projects
  include_projects:
      - PROJ1  # or, 123 for Gitlab

  # Uncomment this to pull from all but specific projects (not supported for GitHub, GitLab, BitbucketCloud, or Azure Devops).
  # Bitbucket Server: use project keys, not names (e.g.: PROJ1)
  #  exclude_projects:
  #    - PROJ1  # or, 123 for Gitlab


  # Only pull from specific repos.  Comment this out to pull from all repos.
  # Bitbucket Server, Bitbucket Cloud, GitHub or Azure Devops: use repository name (e.g.: my_repository)
  # GitLab: use gitlab "Project ID" (e.g.: 123) (not gitlab project name). Comment out to pull all Gitlab Projects
  include_repos:
      - my_repository  # or, 123 for Gitlab

  # Uncomment this to pull from all but specific repos.
  # Bitbucket Server, Bitbucket Cloud, GitHub or Azure Devops: use repository name (e.g.: my_repository)
  # GitLab: use gitlab "Project ID" (e.g.: 123) (not gitlab project name)
  # exclude_repos:
  #    - my_repository  # or, 123 for Gitlab

  # Uncomment this to pull commit data from each of the specified branches for each repository in addition to
  # the repo's default branch. If no branches are provided here, commits will only be pulled from each repository's
  # default branch. Branch names may be either a full branch name or a branch name pattern with the special characters * or ?.
  #   * will match against all subsequent characters. For example, dev* will match against the branches 'dev', 'develop', 'dev_1' etc.
  #   ? will match against a single character. For example, dev? will match against the branches 'dev1', 'dev2', 'dev3' etc.
  #
  # include_branches:
  #   my_repository:
  #     - master
  #     - develop

  # Strip out long-form text content (commit messages, PR text, etc).
  strip_text_content: False

  # Redact names and URLs for projects, repos, branches.
  redact_names_and_urls: False

  # More verbose local logging (currently only available for Bitbucket Server and Bitbucket
  # Cloud).
  verbose: False

######################################
# 3b. Multiple instance config example
#
# Note: all of the fields from the single instance config example are available
# to each instance in a multiple-instance configuration (include_projects,
# exclude_projects, etc.), but for brevity most of those fields are excluded
# from this example.
######################################
git:
  - provider: bitbucket_server
    url: https://bitbucket-org1.yourcompany.com
    # Instance identifier slug, provided by Jellyfish.
    instance_slug: git_instance_slug_1
    # Prefix of your choice to append to the environment variables in creds.env
    # for this instance.  E.g., for a Bitbucket Server instance, if this is set
    # to ORG1, then the environment variables from which the Bitbucket Server
    # credentials are taken will be ORG1_BITBUCKET_USERNAME and
    # ORG1_BITBUCKET_PASSWORD.
    creds_envvar_prefix: ORG1
  - provider: bitbucket_server
    url: https://bitbucket-org2.yourcompany.com
    instance_slug: git_instance_slug_2
    creds_envvar_prefix: ORG2