## Atlassian Bitbucket Data Center Helm values
#
# HEADS UP!
#
# Data loss will occur if sections declared as 'REQUIRED' are not configured appropriately!
# These sections are:
# - database
# - volumes
#
# Additional details on pre-provisioning these required resources can be found here:
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#3-configure-database
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#5-configure-persistent-storage
#
# To manage external access to the Bitbucket instance, an ingress resource can also be configured
# under the 'ingress' stanza. This requires a pre-provisioned ingress controller to be present.
#
# Additional details on pre-provisioning an ingress controller can be found here:
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#4-configure-ingress
#
# Unlike the other products, Bitbucket has the added advantage that it can be fully
# configured at deployment. For a fully configured Bitbucket instance that does not
# require manual configuration post deployment the following sections should all be
# configured:
# - database
# - volumes
# - bitbucket.license
# - bitbucket.sysadminCredentials
# - bitbucket.elasticSearch
#
##

# -- The initial number of Bitbucket pods that should be started at deployment time.
# Note that if Bitbucket is fully configured (see above) during initial deployment
# a 'replicaCount' greater than 1 can be supplied.
#
replicaCount: 1

# -- Image configuration
#
image:
  # -- The Confluence Docker image to use
  # https://hub.docker.com/r/atlassian/bitbucket-server
  #
  repository: atlassian/bitbucket

  # -- Image pull policy
  #
  pullPolicy: IfNotPresent

  # -- The docker image tag to be used - defaults to the Chart appVersion
  #
  tag: ""

# K8s ServiceAccount configuration. Give fine-grained identity and authorization
# to Pods
#
serviceAccount:
  # -- Set to 'true' if a ServiceAccount should be created, or 'false' if it
  # already exists.
  #
  create: true

  # -- The name of the ServiceAccount to be used by the pods. If not specified, but
  # the "serviceAccount.create" flag is set to 'true', then the ServiceAccount name
  # will be auto-generated, otherwise the 'default' ServiceAccount will be used.
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
  #
  name:

  # -- For Docker images hosted in private registries, define the list of image pull
  # secrets that should be utilized by the created ServiceAccount
  # https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
  #
  imagePullSecrets: []
  # - name: secretName

  # -- Annotations to add to the ServiceAccount (if created)
  #
  annotations: {}

  role:
    # -- Create a role for Hazelcast client with privileges to get and list pods and endpoints in the namespace.
    # Set to false if you need to create a Role and RoleBinding manually
    #
    create: true

  # Define permissions
  # https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole
  #
  clusterRole:
    # -- Set to 'true' if a ClusterRole should be created, or 'false' if it
    # already exists.
    #
    create: false

    # -- The name of the ClusterRole to be used. If not specified, but
    # the "serviceAccount.clusterRole.create" flag is set to 'true',
    # then the ClusterRole name will be auto-generated.
    #
    name:

  # -- Grant permissions defined in Role (list and get pods and endpoints) to a service account.
  #
  roleBinding:
    # Set to false if you need to create a Role and RoleBinding manually
    #
    create: true

  # Grant permissions defined in ClusterRole
  # https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
  #
  clusterRoleBinding:
    # -- Set to 'true' if a ClusterRoleBinding should be created, or 'false' if it
    # already exists.
    #
    create: false

    # -- The name of the ClusterRoleBinding to be created. If not specified, but
    # the "serviceAccount.clusterRoleBinding.create" flag is set to 'true',
    # then the ClusterRoleBinding name will be auto-generated.
    #
    name:

# REQUIRED - Database configuration
#
# Bitbucket requires a backend database. The configuration below can be used to define the
# database to use and its connection details.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#database-connectivity
#
database:
  # -- The jdbc URL of the database. If not specified, then it will need to be provided
  # via the browser during manual configuration post deployment. Example URLs include:
  # - 'jdbc:postgresql://<dbhost>:5432/<dbname>'
  # - 'jdbc:mysql://<dbhost>/<dbname>'
  # - 'jdbc:sqlserver://<dbhost>:1433;databaseName=<dbname>'
  # - 'jdbc:oracle:thin:@<dbhost>:1521:<SID>'
  # https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#databaseurl
  #
  url:

  # -- The Java class name of the JDBC driver to be used. If not specified, then it will
  # need to be provided via the browser during manual configuration post deployment.
  # Valid drivers are:
  # - 'org.postgresql.Driver'
  # - 'com.mysql.jdbc.Driver'
  # - 'oracle.jdbc.OracleDriver'
  # - 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
  # https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#databasedriver:
  #
  driver:

  # JDBC connection credentials
  #
  credentials:
    # -- The name of the K8s Secret that contains the database login credentials.
    # If the secret is specified, then the credentials will be automatically utilised on
    # Bitbucket startup. If the secret is not provided, then the credentials will need
    # to be provided via the browser during manual configuration post deployment.
    #
    # Example of creating a database credentials K8s secret below:
    # 'kubectl create secret generic <secret-name> --from-literal=username=<username> \
    # --from-literal=password=<password>'
    # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
    #
    secretName:

    # -- The key ('username') in the Secret used to store the database login username
    #
    usernameSecretKey: username

    # -- The key ('password') in the Secret used to store the database login password
    #
    passwordSecretKey: password

# REQUIRED - Volume configuration
#
# By default, the charts will configure the local-home and shared-home as ephemeral
# volumes i.e. 'emptyDir: {}'. This is fine for evaluation purposes but for production
# deployments this is not ideal and so local-home and shared-home should both be configured
# appropriately.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#volumes
#
volumes:
  # Each pod requires its own volume for 'local-home'. This is needed for key data
  # that help define how Bitbucket works.
  # https://confluence.atlassian.com/bitbucketserver/set-the-home-directory-776640890.html
  #
  localHome:
    # Dynamic provisioning of local-home using the K8s Storage Classes
    #
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic
    # https://atlassian.github.io/data-center-helm-charts/examples/storage/aws/LOCAL_STORAGE/
    #
    persistentVolumeClaim:
      # -- If 'true', then a 'PersistentVolume' and 'PersistentVolumeClaim' will be dynamically
      # created for each pod based on the 'StorageClassName' supplied below.
      #
      create: true

      # -- Specify the name of the 'StorageClass' that should be used for the local-home
      # volume claim.
      #
      storageClassName: vsan-default-storage-policy

      # -- Specifies the standard K8s resource requests and/or limits for the local-home
      # volume claims.
      #
      resources:
        requests:
          storage: 1Gi

    # -- Static provisioning of local-home using K8s PVs and PVCs
    #
    # NOTE: Due to the ephemeral nature of pods this approach to provisioning volumes for
    # pods is not recommended. Dynamic provisioning described above is the prescribed
    # approach.
    #
    # When 'persistentVolumeClaim.create' is 'false', then this value can be used to define
    # a standard K8s volume that will be used for the local-home volume(s). If not defined,
    # then an 'emptyDir' volume is utilised. Having provisioned a 'PersistentVolume', specify
    # the bound 'persistentVolumeClaim.claimName' for the 'customVolume' object.
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static
    #
    customVolume: {}
    # persistentVolumeClaim:
    #   claimName: "<pvc>"

    # -- Specifies the path in the Bitbucket container to which the local-home volume will be
    # mounted.
    #
    mountPath: "/var/atlassian/application-data/bitbucket"

  # An NFS volume for 'shared-home' is required by Bitbucket to effectively operate in multi-node
  # environment.
  #
  # Details on how an NFS should be stood up for Bitbucket can be found here:
  # https://confluence.atlassian.com/bitbucketserver/install-bitbucket-data-center-872139817.html#InstallBitbucketDataCenter-nfs
  #
  # Additional information on utilizing an NFS with the Helm charts can be found here:
  # https://atlassian.github.io/data-center-helm-charts/examples/storage/nfs/NFS/
  #
  sharedHome:
    # Provision a PersistentVolume for an existing NFS server
    #
    persistentVolume:
      # -- If 'true' then a 'PersistentVolume' will be created for the NFS server
      #
      create: false

      # NFS server details for which the PersistentVolume should be created.
      #
      nfs:
        # -- The address of the NFS server. It needs to be resolvable by the kubelet,
        # so consider using an IP address.
        #
        server: ""

        # -- Specifies NFS directory share. This will be mounted into the Pod(s) using the
        # 'volumes.sharedHome.mountPath'
        #
        path: ""

      # -- Additional options to be used when mounting the NFS volume
      #
      mountOptions: []

    # Create a claim for the NFS PersistentVolume
    #
    persistentVolumeClaim:
      # -- If 'true', then a 'PersistentVolumeClaim' will be created for the 'PersistentVolume'
      #
      create: false

      # -- Specify the name of the 'StorageClass' that should be used
      #
      # If set to non-empty string value, this will specify the storage class to be used.
      # If left without value, the default Storage Class will be utilised. Alternatively,
      # can be set to the empty string "", to indicate that no Storage Class should be used here.
      storageClassName: vsan-default-storage-policy

      # -- If persistentVolume.create and persistentVolumeClaim.create are both true then any
      # value supplied here is ignored and the default used. A custom value here is useful
      # when bringing your own 'PersistentVolume' i.e. 'persistentVolume.create' is false.
      #
      volumeName:

      # -- Specifies the access mode of the volume to claim
      #
      accessMode: ReadWriteMany

      # -- Specifies the standard K8s resource requests and/or limits for the shared-home
      #volume claims.
      #
      resources:
        requests:
          storage: 1Gi

    # -- Static provisioning of shared-home using K8s PVs and PVCs
    #
    # When 'persistentVolume.create' and 'persistentVolumeClaim.create' are 'false', then
    # this property can be used to define a custom volume that will be used for shared-home
    # If not defined, then an 'emptyDir' volume is utilised.
    #
    # Having manually provisioned a 'PersistentVolume' with corresponding 'PersistentVolumeClaim'
    # specify the bound claim name below
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static
    # https://atlassian.github.io/data-center-helm-charts/examples/storage/aws/SHARED_STORAGE/
    #
    customVolume: {}
    # persistentVolumeClaim:
    #   claimName: "<pvc>"

    # -- Specifies the path in the Bitbucket container to which the shared-home volume will be
    # mounted.
    #
    mountPath: "/var/atlassian/application-data/shared-home"

    # -- Specifies the sub-directory of the shared-home volume that will be mounted in to the
    # Bitbucket container.
    #
    subPath:

    # Modify permissions on shared-home
    #
    nfsPermissionFixer:
      # -- If 'true', this will alter the shared-home volume's root directory so that Bitbucket
      # can write to it. This is a workaround for a K8s bug affecting NFS volumes:
      # https://github.com/kubernetes/examples/issues/260
      #
      enabled: true

      # -- The path in the K8s initContainer where the shared-home volume will be mounted
      #
      mountPath: "/shared-home"

      # -- Image repository for the permission fixer init container. Defaults to alpine
      #
      imageRepo: alpine
      # -- Image tag for the permission fixer init container. Defaults to latest
      #
      imageTag: latest

      # -- By default, the fixer will change the group ownership of the volume's root directory
      # to match the Bitbucket container's GID (2003), and then ensures the directory is
      # group-writeable. If this is not the desired behaviour, command used can be specified
      # here.
      #
      command:

  # -- Defines additional volumes that should be applied to all Bitbucket pods.
  # Note that this will not create any corresponding volume mounts;
  # those need to be defined in bitbucket.additionalVolumeMounts
  #
  additional: []

# Ingress configuration
#
# To make the Atlassian product available from outside the K8s cluster an Ingress
# Controller should be pre-provisioned. With this in place the configuration below
# can be used to configure an appropriate Ingress Resource.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#ingress
#
ingress:
  # -- Set to 'true' if an Ingress Resource should be created. This depends on a
  # pre-provisioned Ingress Controller being available.
  #
  create: true

  # -- The class name used by the ingress controller if it's being used.
  #
  # Please follow documentation of your ingress controller. If the cluster
  # contains multiple ingress controllers, this setting allows you to control
  # which of them is used for Atlassian application traffic.
  #
  className: "contour"

  # -- Set to 'true' if the Ingress Resource is to use the K8s 'ingress-nginx'
  # controller.
  # https://kubernetes.github.io/ingress-nginx/
  #
  # This will populate the Ingress Resource with annotations that are specific to
  # the K8s ingress-nginx controller. Set to 'false' if a different controller is
  # to be used, in which case the appropriate annotations for that controller must
  # be specified below under 'ingress.annotations'.
  #
  nginx: false

  # -- The max body size to allow. Requests exceeding this size will result
  # in an HTTP 413 error being returned to the client.
  #
  maxBodySize: 250m

  # -- Defines a timeout for establishing a connection with a proxied server. It should
  # be noted that this timeout cannot usually exceed 75 seconds.
  #
  proxyConnectTimeout: 60

  # -- Defines a timeout for reading a response from the proxied server. The timeout is
  # set only between two successive read operations, not for the transmission of the
  # whole response. If the proxied server does not transmit anything within this time,
  # the connection is closed.
  #
  proxyReadTimeout: 60

  # -- Sets a timeout for transmitting a request to the proxied server. The timeout is set
  # only between two successive write operations, not for the transmission of the whole
  # request. If the proxied server does not receive anything within this time, the
  # connection is closed.
  #
  proxySendTimeout: 60

  # -- The fully-qualified hostname (FQDN) of the Ingress Resource. Traffic coming in on
  # this hostname will be routed by the Ingress Resource to the appropriate backend
  # Service.
  #
  host: atlassian-test.saltlabs.cloud

  # -- The base path for the Ingress Resource. For example '/bitbucket'. Based on a
  # 'ingress.host' value of 'company.k8s.com' this would result in a URL of
  # 'company.k8s.com/bitbucket'. Default value is 'bitbucket.service.contextPath'.
  #
  path: "/bitbucket"

  # -- The custom annotations that should be applied to the Ingress Resource
  # when NOT using the K8s ingress-nginx controller.
  #
  annotations:
    cert-manager.io/issuer: ca-selfsigned-issuer

  # -- Set to 'true' if browser communication with the application should be TLS
  # (HTTPS) enforced.
  #
  https: false

  # -- The name of the K8s Secret that contains the TLS private key and corresponding
  # certificate. When utilised, TLS termination occurs at the ingress point where
  # traffic to the Service, and it's Pods is in plaintext.
  #
  # Usage is optional and depends on your use case. The Ingress Controller itself
  # can also be configured with a TLS secret for all Ingress Resources.
  # https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
  # https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
  #
  tlsSecretName:

# Bitbucket configuration
#
bitbucket:
  # K8s Service configuration
  #
  service:
    # -- The port on which the Bitbucket K8s Service will listen
    #
    port: 80

    # -- The type of K8s service to use for Bitbucket
    #
    type: ClusterIP

    # -- Use specific loadBalancerIP. Only applies to service type LoadBalancer.
    #
    loadBalancerIP:

    # -- The context path that Bitbucket will use.
    #
    contextPath:

    # -- Additional annotations to apply to the Service
    #
    annotations: {}

  # -- Enable or disable an additional service for exposing SSH for external access.
  # Disable when the SSH service is exposed through the ingress controller, or
  # enable if the ingress controller does not support TCP.
  #
  sshService:
    # -- Set to 'true' if an additional SSH Service should be created
    #
    enabled: false

    # -- Port to expose the SSH service on.
    #
    port: 22

    # -- The hostname of the SSH service. If set, it'll be used to configure the SSH base URL for the application.
    #
    host:

    # -- SSH Service type
    #
    type: LoadBalancer

    # -- Use specific loadBalancerIP. Only applies to service type LoadBalancer.
    #
    loadBalancerIP:

    # -- Annotations for the SSH service. Useful if a load balancer controller
    # needs extra annotations.
    #
    annotations: {}

  # Standard K8s field that holds pod-level security attributes and common container settings.
  # https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  # Do not populate when deploying to OpenShift, unless anyuid policy is attached to a service account.
  #

  # -- Whether to apply security context to pod.
  #
  securityContextEnabled: true

  securityContext:
    # -- The GID used by the Bitbucket docker image
    # GID will default to 2003 if not supplied and securityContextEnabled is set to true.
    # This is intended to ensure that the shared-home volume is group-writeable by the GID used by the Bitbucket container.
    # However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
    #
    fsGroup: 2003

  # -- Standard K8s field that holds security configurations that will be applied to a container.
  # https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  #
  containerSecurityContext: {}

  # -- Boolean to define whether to set local home directory permissions on startup
  # of Bitbucket container. Set to 'false' to disable this behaviour.
  #
  setPermissions: true

  # Port definitions
  #
  ports:
    # -- The port on which the Bitbucket container listens for HTTP traffic
    #
    http: 7990

    # -- The port on which the Bitbucket container listens for SSH traffic
    #
    ssh: 7999

    # -- The port on which the Hazelcast listens for client traffic
    #
    hazelcast: 5701

  # Bitbucket licensing details
  #
  license:
    # -- The name of the K8s Secret that contains the Bitbucket license key. If specified, then
    # the license will be automatically populated during Bitbucket setup. Otherwise, it will
    # need to be provided via the browser after initial startup. An Example of creating
    # a K8s secret for the license below:
    # 'kubectl create secret generic <secret-name> --from-literal=license-key=<license>
    # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
    #
    secretName:

    # -- The key in the K8s Secret that contains the Bitbucket license key
    #
    secretKey: license-key

  # Bitbucket system administrator credential config
  # https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/?h=sysad#7-configure-license
  #
  sysadminCredentials:
    # -- The name of the Kubernetes Secret that contains the Bitbucket sysadmin credentials
    # If specified, then these will be automatically populated during Bitbucket setup.
    # Otherwise, they will need to be provided via the browser after initial startup.
    #
    secretName:

    # -- The key in the Kubernetes Secret that contains the sysadmin username
    #
    usernameSecretKey: username

    # -- The key in the Kubernetes Secret that contains the sysadmin password
    #
    passwordSecretKey: password

    # -- The key in the Kubernetes Secret that contains the sysadmin display name
    #
    displayNameSecretKey: displayName

    # -- The key in the Kubernetes Secret that contains the sysadmin email address
    #
    emailAddressSecretKey: emailAddress

  # -- Set the display name of the Bitbucket instance. Note that this value is only used during installation and
  # changing the value during an upgrade has no effect.
  #
  displayName:

  # Data Center clustering
  #
  clustering:
    # -- Set to 'true' if Data Center clustering should be enabled
    # This will automatically configure cluster peer discovery between cluster nodes.
    #
    enabled: false

    # Hazelcast group configuration secrets. If left unchanged, a default group name and a random password will be
    # generated on installation.
    #
    group:
      # -- The name of the Kubernetes Secret that contains the Hazelcast group credentials.
      # Example of creating a credentials K8s secret below:
      # 'kubectl create secret generic <secret-name> --from-literal=name=<name> \
      # --from-literal=password=<password>'
      # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
      #
      # If no secret is specified, a default group name will be used and a random password will be generated during
      # installation.
      #
      secretName:

      # -- The key in the Kubernetes Secret that contains the Hazelcast group name.
      #
      nameSecretKey: name

      # -- The key in the Kubernetes Secret that contains the Hazelcast group password.
      #
      passwordSecretKey: password

  # Elasticsearch config
  #
  elasticSearch:
    # -- The base URL of the external Elasticsearch instance to be used, for example:
    # http://elasticsearch-master.<namespace>.svc.cluster.local:9200
    # If this is defined, then Bitbucket will disable its internal Elasticsearch instance.
    #
    baseUrl:

    # Elasticsearch's connection details
    #
    credentials:
      # -- The name of the Kubernetes Secret that contains the Elasticsearch credentials.
      # Example of creating a credentials K8s secret below:
      # 'kubectl create secret generic <secret-name> --from-literal=username=<username> \
      # --from-literal=password=<password>'
      # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
      #
      secretName:

      # -- The key in the Kubernetes Secret that contains the Elasticsearch username.
      #
      usernameSecretKey: username

      # -- The key in the Kubernetes Secret that contains the Elasticsearch password.
      #
      passwordSecretKey: password

  shutdown:
    # -- The termination grace period for pods during shutdown. This
    # should be set to the Bitbucket internal grace period (default 30
    # seconds), plus a small buffer to allow the JVM to fully terminate.
    #
    terminationGracePeriodSeconds: 35

    # -- By default pods will be stopped via a [preStop hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/),
    # using a script supplied by the Docker image. If any other
    # shutdown behaviour is needed it can be achieved by overriding
    # this value. Note that the shutdown command needs to wait for the
    # application shutdown completely before exiting; see [the default
    # command](https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/src/master/shutdown-wait.sh)
    # for details.
    #
    command: "/shutdown-wait.sh"

  # -- Pod management strategy. Bitbucket Data Center requires the "OrderedReady" value but for Bitbucket Mirrors you
  # can use the "Parallel" option.
  # To learn more, visit https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-management-policies
  #
  podManagementStrategy: OrderedReady

  # Pod resource requests
  #
  resources:
    # JVM Memory / Heap Size definitions. These values below are based on the
    # defaults defined for the Bitbucket docker container.
    # https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/src/master/
    #
    jvm:
      # -- The maximum amount of heap memory that will be used by the Bitbucket JVM
      # The same value will be used by the Elasticsearch JVM.
      maxHeap: "1g"

      # -- The minimum amount of heap memory that will be used by the Bitbucket JVM
      # The same value will be used by the Elasticsearch JVM.
      minHeap: "512m"

    # Specifies the standard K8s resource requests and/or limits for the Bitbucket
    # container. It is important that if the memory resources are specified here,
    # they must allow for the size of the Bitbucket JVM. That means the maximum heap
    # size, the reserved code cache size, plus other JVM overheads, must be
    # accommodated. Allowing for (maxHeap+codeCache)*1.5 would be an example.
    #
    container:
      requests:
        # -- Initial CPU request by Bitbucket pod
        #
        cpu: "2"

        # -- Initial Memory request by Bitbucket pod
        #
        memory: "2G"
      #  limits:
      #    cpu: "2"
      #    memory: "2G"

  # -- Application Mode
  #
  # This can be either 'default' or 'mirror'
  #
  applicationMode: "default"

  # Mirror Configuration
  #
  mirror:
    # -- Specifies the URL of the upstream Bitbucket server for this mirror.
    #
    upstreamUrl:

  # Mesh configuration
  mesh:
    # -- Enable Bitbucket Mesh. See: https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-1128304351.html
    #
    enabled: false

    # -- Experimental! Automatically register Bitbucket mesh nodes with the Bitbucket server.
    # `bitbucket.sysadminCredentials.secretName` needs to be defined to provide credentials
    # to post-install node registration jobs that are created only for new Helm chart installations.
    # It is recommended to manually register Mesh nodes in Butbucket UI.
    #
    nodeAutoRegistration: false

    # -- Experimental! Automatically create all new repositories on Bitbucket mesh nodes.
    # `bitbucket.sysadminCredentials.secretName` needs to be defined to provide credentials
    # to node post-install job. It is recommended to manually configure it in Bitbucket UI.
    #
    setByDefault: false

    # -- The Bitbucket Mesh image to use
    # https://hub.docker.com/r/atlassian/bitbucket-mesh
    #
    image:
      # -- The Bitbucket Mesh image repository
      # https://hub.docker.com/r/atlassian/bitbucket-mesh
      #
      repository: atlassian/bitbucket-mesh

      # -- Image pull policy
      #
      pullPolicy: IfNotPresent

      # -- The docker image tag to be used
      #
      tag: "1.5.0"

    # -- Number of Bitbucket Mesh nodes. Do not change it. Currently, only the quorum of 3 mesh nodes is supported.
    # Reducing the number of replicas will result in mesh degradation while increasing the number of Mesh nodes
    # will result in new nodes being unused by the Bitbucket server.
    #
    replicaCount: 3

    service:
      # -- Bitbucket Mesh port
      #
      port: 7777

      # -- The type of K8s service to use for Bitbucket mesh service
      #
      type: ClusterIP

      # -- Use specific loadBalancerIP. Only applies to service type LoadBalancer.
      #
      loadBalancerIP:

      # -- Bitbucket mesh service annotations
      #
      annotations: {}

    # -- Custom annotations that will be applied to all Bitbucket Mesh pods
    #
    podAnnotations: {}
    #  name: <value>

    # -- Custom labels that will be applied to all Bitbucket Mesh pods
    #
    podLabels: {}
    #  name: <value>

    # -- Bitbucket Mesh resources requests and limits
    #
    resources:
      # -- Bitbucket Mesh JVM heap settings
      #
      jvm:
        maxHeap: "1g"
        minHeap: "512m"

      # -- Bitbucket Mesh container cpu/mem requests and limits
      #
      container:
        requests:
          cpu: "1"
          memory: "2G"
        limits:
          cpu: "2"
          memory: "2G"

    # -- Mesh home volume settings. Disabling persistence results in data loss!
    #
    volume:
      create: true
      resources:
        requests:
          storage: 1Gi
      storageClass:
      mountPath: "/var/atlassian/application-data/mesh"

    # -- Defines any additional environment variables to be passed to the Bitbucket mesh containers.
    #
    additionalEnvironmentVariables: {}

    # -- Specifies a list of additional arguments that can be passed to the Bitbucket Mesh JVM, e.g.
    # system properties.
    #
    additionalJvmArgs: []

    # -- Additional initContainer definitions that will be added to all Bitbucket pods
    #
    additionalInitContainers: {}
    #  - name: <name>
    #    image: <image>:<tag>

    # -- Additional existing ConfigMaps and Secrets not managed by Helm that should be
    # mounted into service container
    #
    additionalFiles:
    # Example:
    # - name: keystore
    #   type: secret
    #   key: keystore.jks
    #   mountPath: /var/ssl

    # -- Standard K8s node-selectors that will be applied to all Bitbucket Mesh pods
    #
    nodeSelector: {}
    #  name: <value>

    # -- Standard Kubernetes affinities that will be applied to all Bitbucket mesh pods
    #
    affinity: {}

    # -- Standard K8s tolerations that will be applied to all Bitbucket Mesh pods
    #
    tolerations: {}
    # - effect: <name>
    #   operator: <operator>
    #   key: <key>

    # -- Defines topology spread constraints for Bitbucket Mesh pods. See details:
    # https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/
    #
    topologySpreadConstraints: {}
    # - maxSkew: 1
    #   topologyKey: kubernetes.io/hostname
    #   whenUnsatisfiable: ScheduleAnyway
    #   labelSelector:
    #     matchLabels:

    # -- Standard K8s schedulerName that will be applied to all Bitbucket pods.
    # Check Kubernetes documentation on how to configure multiple schedulers:
    # https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#specify-schedulers-for-pods
    #
    schedulerName:

    # See: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-management-policies
    #
    podManagementPolicy: OrderedReady

    shutdown:
      # -- The termination grace period for pods during shutdown. This
      # should be set to the Bitbucket internal grace period (default 30
      # seconds), plus a small buffer to allow the JVM to fully terminate.
      #
      terminationGracePeriodSeconds: 35

  # -- Specifies a list of additional arguments that can be passed to the Bitbucket JVM, e.g.
  # system properties.
  #
  additionalJvmArgs: []

  # -- Specifies a list of additional Java libraries that should be added to the
  # Bitbucket container. Each item in the list should specify the name of the volume
  # that contains the library, as well as the name of the library file within that
  # volume's root directory. Optionally, a subDirectory field can be included to
  # specify which directory in the volume contains the library file. Additional details:
  # https://atlassian.github.io/data-center-helm-charts/examples/external_libraries/EXTERNAL_LIBS/
  #
  additionalLibraries: []
  #  - volumeName:
  #    subDirectory:
  #    fileName:

  # -- Specifies a list of additional Bitbucket plugins that should be added to the
  # Bitbucket container. Note plugins installed via this method will appear as
  # bundled plugins rather than user plugins. These should be specified in the same
  # manner as the 'additionalLibraries' property. Additional details:
  # https://atlassian.github.io/data-center-helm-charts/examples/external_libraries/EXTERNAL_LIBS/
  #
  # NOTE: only .jar files can be loaded using this approach. OBR's can be extracted
  # (unzipped) to access the associated .jar
  #
  # An alternative to this method is to install the plugins via "Manage Apps" in the
  # product system administration UI.
  #
  additionalBundledPlugins: []
  #  - volumeName:
  #    subDirectory:
  #    fileName:

  # -- Defines any additional volumes mounts for the Bitbucket container. These
  # can refer to existing volumes, or new volumes can be defined via
  # 'volumes.additional'.
  #
  additionalVolumeMounts: []

  # -- Defines any additional environment variables to be passed to the Bitbucket
  # container. See https://hub.docker.com/r/atlassian/bitbucket-server for
  # supported variables.
  #
  additionalEnvironmentVariables: []

  # -- Defines any additional ports for the Bitbucket container.
  #
  additionalPorts: []
  #  - name: jmx
  #    containerPort: 5555
  #    protocol: TCP

  # -- Defines additional volumeClaimTemplates that should be applied to the Bitbucket pod.
  # Note that this will not create any corresponding volume mounts;
  # those needs to be defined in bitbucket.additionalVolumeMounts
  #
  additionalVolumeClaimTemplates: []
  #  - name: myadditionalvolumeclaim
  #    storageClassName:
  #    resources:
  #      requests:
  #        storage: 1Gi

  # -- Defines topology spread constraints for Bitbucket pods. See details:
  # https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/
  #
  topologySpreadConstraints: []
  # - maxSkew: 1
  #   topologyKey: kubernetes.io/hostname
  #   whenUnsatisfiable: ScheduleAnyway
  #   labelSelector:
  #     matchLabels:

# Fluentd configuration
#
# Bitbucket log collection and aggregation can be enabled using Flunetd. This config
# assumes an existing ELK stack has been stood up and is available.
# https://www.fluentd.org/
#
fluentd:
  # -- Set to 'true' if the Fluentd sidecar (DaemonSet) should be added to each pod
  #
  enabled: false

  # -- The Fluentd sidecar image repository
  #
  imageRepo: fluent/fluentd-kubernetes-daemonset
  # -- The Fluentd sidecar image tag
  #
  imageTag: v1.11.5-debian-elasticsearch7-1.2

  # -- The command used to start Fluentd. If not supplied the default command
  # will be used: "fluentd -c /fluentd/etc/fluent.conf -v"
  #
  # Note: The custom command can be free-form, however pay particular attention to
  # the process that should ultimately be left running in the container. This process
  # should be invoked with 'exec' so that signals are appropriately propagated to it,
  # for instance SIGTERM. An example of how such a command may look is:
  # "<command 1> && <command 2> && exec <primary command>"
  command:

  # -- Set to 'true' if a custom config (see 'configmap-fluentd.yaml' for default)
  # should be used for Fluentd. If enabled this config must be supplied via the
  # 'fluentdCustomConfig' property below.
  #
  customConfigFile: false

  # -- Custom fluent.conf file
  #
  fluentdCustomConfig: {}
  # fluent.conf: |
  #   <source>
  #     @type tail
  #     <parse>
  #     @type multiline
  #     format_firstline /\d{4}-\d{1,2}-\d{1,2}/
  #     </parse>
  #     path /application-data/logs/atlassian-bitbucket-access.log*
  #     pos_file /tmp/bitbucketlog.pos
  #     tag bitbucket-access-logs
  #   </source>

  # Elasticsearch config based on your ELK stack
  #
  elasticsearch:
    # -- Set to 'true' if Fluentd should send all log events to an Elasticsearch service.
    #
    enabled: true

    # -- The hostname of the Elasticsearch service that Fluentd should send logs to.
    #
    hostname: elasticsearch

  # -- Specify custom volumes to be added to Fluentd container (e.g. more log sources)
  #
  extraVolumes: []
  # - name: local-home
  #   mountPath: application-data/logs
  #   subPath: log
  #   readOnly: true

# -- Custom annotations that will be applied to all Bitbucket pods
#
podAnnotations: {}
#  name: <value>

# -- Custom labels that will be applied to all Bitbucket pods
#
podLabels: {}
#  name: <value>

# -- Standard K8s node-selectors that will be applied to all Bitbucket pods
#
nodeSelector: {}
#  name: <value>

# -- Standard K8s tolerations that will be applied to all Bitbucket pods
#
tolerations: []
# - effect: <name>
#   operator: <operator>
#   key: <key>

# -- Standard Kubernetes affinities that will be applied to all Bitbucket pods
# Due to the performance requirements it is highly recommended running all Bitbucket pods
# in the same availability zone as your dedicated NFS server. To achieve this, you
# can define `affinity` and `podAffinity` rules that will place all pods into the same zone,
# and therefore minimise the real distance between the application pods and the shared storage.
# More specific documentation can be found in the official Affinity and Anti-affinity documentation:
#  https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
#
# This is an example on how to ensure the pods are in the same zone as NFS server that is labeled with `role=nfs-server`:
#
#   podAffinity:
#    requiredDuringSchedulingIgnoredDuringExecution:
#      - labelSelector:
#          matchExpressions:
#            - key: role
#              operator: In
#              values:
#                - nfs-server # needs to be the same value as NFS server deployment
#        topologyKey: topology.kubernetes.io/zone
affinity: {}

# -- Standard K8s schedulerName that will be applied to all Bitbucket pods.
# Check Kubernetes documentation on how to configure multiple schedulers:
# https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#specify-schedulers-for-pods
#
schedulerName:

# -- Additional container definitions that will be added to all Bitbucket pods
#
additionalContainers: []
#  - name: <name>
#    image: <image>:<tag>

# -- Additional initContainer definitions that will be added to all Bitbucket pods
#
additionalInitContainers: []
#  - name: <name>
#    image: <image>:<tag>

# -- Additional labels that should be applied to all resources
#
additionalLabels: {}
#  name: <value>

# -- Additional existing ConfigMaps and Secrets not managed by Helm that should be
# mounted into service container. Configuration details below (camelCase is important!):
# 'name'      - References existing ConfigMap or secret name.
# 'type'      - 'configMap' or 'secret'
# 'key'       - The file name.
# 'mountPath' - The destination directory in a container.
# VolumeMount and Volumes are added with this name and index position, for example;
# custom-config-0, keystore-2
#
additionalFiles: []
# Examples:
#  - name: custom-config
#    type: configMap
#    key: log4j.properties
#    mountPath:  /var/atlassian
#  - name: custom-config
#    type: configMap
#    key: web.xml
#    mountPath: /var/atlassian
#  - name: keystore
#    type: secret
#    key: keystore.jks
#    mountPath: /var/ssl