Skip to content

Files that require bigbang integration testing📜

See bb MR testing for details regarding testing changes against bigbang umbrella chart.📜

There are certain integrations within the bigbang ecosystem and this package that require additional testing outside of the specific package tests ran during CI. This is a requirement when files within those integrations are changed, as to avoid causing breaks up through the bigbang umbrella. Currently, these include changes to the istio implementation within sonarqube (see: istio templates, network policy templates, service entry templates).

Holocron has collectors built into multiple packages (see Gitlab, SonarQube, Jira) that will require some manual testing as well as validating against the bigbang umbrella chart. It is ideal to test holocron against bigbang umbrella if any changes are made to the layered templates within chart/templates/, as well as collector values within chart/values.yaml.

Be sure to also test against monitoring locally as it is integrated by default with these high-impact service control packages, and needs to be validated using the necessary chart values beneath istio.hardened block with monitoring.enabled set to true as part of your dev-overrides.yaml

Deploy Holocron with Big Bang📜

This is a guide for deploying Holocron as part of Big Bang.

BigBang cluster📜

Clone the latest version of Big Bang:

git clone https://repo1.dso.mil/big-bang/bigbang.git

Change directory into bigbang and run k3d script to deploy containers:

cd bigbang

./docs/assets/scripts/developer/k3d-dev.sh

Note: The Deployment Process and Pre-Requisites will vary depending on the deployment scenario. The Quick Start Demo Deployment for example, allows some steps to be skipped due to a mixture of automation and generically reusable demonstration configuration that satisfies pre-requisites. The following is a general overview of the process, reference the deployment guides for more detail.

Holocron📜

To deploy Holocron, add the following sample override to the values section of the Holocron addon configuration (sample overrides for testing): 

kyverno:
  enabled: true

kyvernoPolicies:
  enabled: true

kyvernoReporter:
  enabled: true

flux:
  interval: 1m
  rollback:
    cleanupOnFail: false  

domain: dev.bigbang.mil
addons:
  holocron: 
    enabled: true
    sourceType: "git"
    git:
      repo: "https://repo1.dso.mil/big-bang/product/packages/holocron.git"     
      tag: null     
      branch: "main"
      path: "./chart"   
    values:
      istio:
        enabled: true
        hardened:
          enabled: true
          customServiceEntries:
            - name: "allow-google"
              enabled: true
              spec:
                exportTo:
                  - "."
                hosts:
                  - google.com
                location: MESH_EXTERNAL
                ports:
                  - number: 443
                    protocol: TLS
                    name: https
              resolution: DNS

Post Deployment Setup📜

Once you have successfully deployed, you will need to assign roles to users. Any user in the admin group will automatically have full rights. They will need to create the organization(s) used and assign users to adminstrate them. For a user to be available, they must have accessed your Holocron instance at least once. More details on setting up Organizations/Value Streams/Teams can be found here.

GitLab📜

Sample Gitlab overrides 

istio:
  enabled: true
istioOperator:
  enabled: true
addons:
  gitlab:
    enabled: true
    values:
      gitlab:
        webservice:
          helmTests:
            enabled: false

If deploying with GitLab, Holocron will attempt to collect metrics from it, but you will need to provide it access. Create an access token for Holocron to utilize. Click here for instructions. It needs read access to all groups and repositories that you want it to collect from. We recommend creating an auditor for this purpose. Provide this access token to .Values.addons.holocron.collectorAuth.gitlabToken.

Post Deployment Value update to Holocron📜

GitLab Deployment with Holocron📜

  1. Access Token Creation:
  2. Holocron requires access to GitLab to collect metrics. To facilitate this, you must create a personal access token.

  3. Follow the instructions provided here to create the token.

  4. Permissions:

  5. Ensure the personal access token has read access to all groups and repositories from which Holocron will collect metrics.

  6. It is recommended to create an auditor account specifically for this purpose to avoid any conflicts or security issues.

  7. Configuration:

  8. Once the personal access token is created, provide this token to Holocron by setting it in .Values.addons.holocron.collectorAuth.gitlabToken.

Sample post deployment override for Holocron:

kyverno:
  enabled: true

kyvernoPolicies:
  enabled: true

kyvernoReporter:
  enabled: true

flux:
  interval: 1m
  rollback:
    cleanupOnFail: false  

domain: dev.bigbang.mil

addons:
  holocron:  
    enabled: true
    sourceType: "git"
    git:
      repo: "https://repo1.dso.mil/big-bang/product/packages/holocron.git"     
      tag: null
      branch: "main"  # deploy from main branch 
      path: "./chart"
    collectorAuth:      # Post Deployment Override
      gitlabToken: "glpat-2-xq5M5zHijxBXwTy-fA"  # Post Deployment Override
    values:
      istio:
        enabled: true
        hardened:
          enabled: true
          customServiceEntries:
            - name: "allow-google"
              enabled: true
              spec:
                exportTo:
                  - "."
                hosts:
                  - google.com
                location: MESH_EXTERNAL
                ports:
                  - number: 443
                    protocol: TLS
                    name: https
              resolution: DNS

Holocron will deploy collectors for Build (pipelines), SCM (commits, branches, MRs), and Workflow (issues). If any of these are not desired, provide an empty array to .Values.addons.holocron.values.<collectorType>.instances. For example, if you do not want to collect issues from GitLab, set .Values.addons.holocron.values.collectorGitlabWorkflow.instances to [].

Verify that the gitlab collector is running and collecting stats by checking the logs of the collector pod. You should see “4XX” errors in the logs if it is not collecting.

SonarQube📜

if deploying with SonarQube, Holocron will attempt to collect metrics from it, but you will need to provide it access. Create an access token for Holocron to utilize. It needs read access to all projects that you want it to collect from. Provide this access token to .Values.addons.holocron.collectorAuth.sonarToken.

If this collection is not desired, set .Values.addons.holocron.values.collectorSonarQubeProjectAnalysis to [].

Jira📜

If deploying with Jira, Holocron will need to be told about it in order to collect metrics from it. If desired, set .Values.addons.holocron.jira.enabled to true and .Values.addons.holocron.jira.service.name to the kubernetes service name (including port). If network policies are enabled, you must also set a key value pair under .Values.addons.holocron.jira.service.label. This should be set to a kubernetes label used by the Jira webservice pod.

Upgrading to a new version📜

The below details the steps required to update to a new version of the Holocron package.

  1. Review the holocron chart CHANGELOG for the update you are going to, as well as any versions skipped over between the last BB release and this one. Note any breaking changes and new features.

  2. Should you have further questions about changelog items, you may want to dig into the per-component repositories for Holocron’s API, dashboard, and collectors.

  3. Based on the changelog review from earlier, make any changes required to resolve breaking changes and reconcile the Big Bang modifications.

  4. Modify the version in Chart.yaml. Also modify the appVersion and the bigbang.dev/applicationVersions to the new version of Holocron.

  5. Update CHANGELOG.md adding an entry for the new version and noting all changes (at minimum should include Updated component-name to x.x.x).

  6. If there are any sub chart dependencies that need to be updated, run helm dep update ./chart

  7. Generate the README.md updates by following the guide in gluon.

  8. Open an MR in “Draft” status and validate that CI passes. This will perform a number of smoke tests against the package, but it is good to manually deploy to test some things that CI doesn’t. Follow the steps below for manual testing.

  9. Once all manual testing is complete take your MR out of “Draft” status and add the review label.