Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Using the Shared-Secrets Job | GitLab

  • Installation command line options

  • Job configuration examples

    • tolerations
  • Disable functionality

Using the Shared-Secrets Job

The shared-secrets job is responsible for provisioning a variety of secrets
used across the installation, unless otherwise manually specified. This includes:

  1. Initial root password
  2. Self-signed TLS certificates for all public services: GitLab, MinIO, and Registry
  3. Registry authentication certificates
  4. MinIO, Registry, GitLab Shell, and Gitaly secrets
  5. Redis and PostgreSQL passwords
  6. SSH host keys
  7. GitLab Rails secret for encrypted credentials

Installation command line options

The table below contains all the possible configurations that can be supplied to
the helm install command using the --set flag:

Parameter Default Description
enabled true See Below
env production Rails environment
podLabels Supplemental Pod labels. Will not be used for selectors.
annotations Supplemental Pod annotations.
image.pullPolicy Always Gitaly image pull policy
image.pullSecrets Secrets for the image repository
image.repository registry.gitlab.com/gitlab-org/build/cng/kubectl Gitaly image repository
image.tag 1f8690f03f7aeef27e727396927ab3cc96ac89e7 Gitaly image tag
Priority class assigned to pods
rbac.create true Create RBAC roles and bindings
resources resource requests, limits
securitContext.fsGroup 65534 User ID to mount filesystems as
securitContext.runAsUser 65534 User ID to run the container as
selfsign.caSubject GitLab Helm Chart selfsign CA Subject
selfsign.image.repository registry.gitlab.com/gitlab-org/build/cnf/cfssl-self-sign selfsign image repository
selfsign.image.pullSecrets Secrets for the image repository
selfsign.image.tag selfsign image tag
selfsign.keyAlgorithm rsa selfsign cert key algorithm
selfsign.keySize 4096 selfsign cert key size
serviceAccount.enabled true Define serviceAccountName on job(s)
serviceAccount.create true Create ServiceAccount
serviceAccount.name RELEASE_NAME-shared-secrets Service account name to specify on job(s) (and on the serviceAccount itself if serviceAccount.create=true )
tolerations [] Toleration labels for pod assignment

Job configuration examples


tolerations allow you schedule pods on tainted worker nodes

Below is an example use of tolerations :

- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"

Disable functionality

Some users may wish to explicitly disable the functionality provided by this job.
To do this, we have provided the enabled flag as a boolean, defaulting to true .

To disable the job, pass --set shared-secrets.enabled=false , or pass the following
in a YAML via the -f flag to helm :

enabled: false

If you disable this job, you must manually create all secrets,
and provide all necessary secret content. See installation/secrets
for further details.
Changelog entries | GitLab

  • Overview
  • What warrants a changelog entry?
  • Writing good changelog entries

  • How to generate a changelog entry

    • History and Reasoning

Changelog entries

This guide contains instructions for when and how to generate a changelog entry
file, as well as information and history about our changelog process.


Each bullet point, or entry , in our
file is generated from the subject line of a Git commit. Commits are included
when they contain the Changelog Git trailer.
When generating the changelog, author and merge request details are added

The Changelog trailer accepts the following values:

  • added
  • fixed
  • changed
  • deprecated
  • removed
  • security
  • performance
  • other

An example of a Git commit to include in the changelog is the following:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

Changelog: changed

GitLab automatically links the merge request to the commit when generating the
changelog. If you want to override the merge request to link to, you can specify
an alternative merge request using the MR trailer:

Update git vendor to gitlab

Now that we are using gitaly to compile git, the git version isn't known
from the manifest, instead we are getting the gitaly version. Update our
vendor field to be `gitlab` to avoid cve matching old versions.

Changelog: changed
MR: https://gitlab.com/foo/bar/-/merge_requests/123

The value must be the full URL of the merge request.

What warrants a changelog entry?

  • Any user-facing change should have a changelog entry. Example: “GitLab now
    uses system fonts for all text.”
  • A fix for a regression introduced and then fixed in the same release (i.e.,
    fixing a bug introduced during a monthly release candidate) should not
    have a changelog entry.
  • Any developer-facing change (e.g., refactoring, technical debt remediation,
    test suite changes) should not have a changelog entry. Example: “Reduce
    database records created during Cycle Analytics model spec.”

  • Any contribution from a community member, no matter how small, may have
    a changelog entry regardless of these guidelines if the contributor wants one.
    Example: “Fixed a typo on the search results page. (Jane Smith)”

Writing good changelog entries

A good changelog entry should be descriptive and concise. It should explain the
change to a reader who has zero context about the change. If you have trouble
making it both concise and descriptive, err on the side of descriptive.

  • Bad: Go to a project order.

  • Good: Show a user’s starred projects at the top of the “Go to project”

The first example provides no context of where the change was made, or why, or
how it benefits the user.

  • Bad: Copy (some text) to clipboard.

  • Good: Update the “Copy to clipboard” tooltip to indicate what’s being

Again, the first example is too vague and provides no context.

  • Bad: Fixes and Improves CSS and HTML problems in mini pipeline graph and
    builds dropdown.

  • Good: Fix tooltips and hover states in mini pipeline graph and builds

The first example is too focused on implementation details. The user doesn’t
care that we changed CSS and HTML, they care about the end result of those

  • Bad: Strip out nil s in the Array of Commit objects returned from

  • Good: Fix 500 errors caused by Elasticsearch results referencing
    garbage-collected commits

The first example focuses on how we fixed something, not on what it fixes.
The rewritten version clearly describes the end benefit to the user (fewer 500
errors), and when (searching commits with Elasticsearch).

Use your best judgement and try to put yourself in the mindset of someone
reading the compiled changelog. Does this entry add value? Does it offer context
about where and why the change was made?

How to generate a changelog entry

Git trailers are added when committing your changes. This can be done using your
text editor of choice. Adding the trailer to an existing commit requires either
amending to the commit (if it’s the most recent one), or an interactive rebase
using git rebase -i .

To update the last commit, run the following:

git commit --amend

You can then add the Changelog trailer to the commit message. If you had
already pushed prior commits to your remote branch, you have to force push
the new commit:

git push -f origin your-branch-name

To edit older (or multiple commits), use git rebase -i HEAD~N where N is the
last N number of commits to rebase. Let’s say you have 3 commits on your branch:
A, B, and C. If you want to update commit B, you need to run:

git rebase -i HEAD~2

This starts an interactive rebase session for the last two commits. When
started, Git presents you with a text editor with contents along the lines of
the following:

pick B Subject of commit B
pick C Subject of commit C

To update commit B, change the word pick to reword , then save and quit the
editor. Once closed, Git presents you with a new text editor instance to edit
the commit message of commit B. Add the trailer, then save and quit the editor.
If all went well, commit B is now updated.

For more information about interactive rebases, take a look at
the Git documentation.

History and Reasoning

This method was adopted from the primary GitLab codebase, as we
found the workflow to be appealing and familiar.

Return to Development documentation

Read article
ChaosKube | GitLab

  • Why
  • How
  • Usage
  • Configuration


ChaosKube is similar to
Netflix’s chaos monkey for Kubernetes
clusters. It schedules random termination of pods in order to test the fault tolerance
of a highly available system.


As a part of our charts development we needed a way to test the fault tolerance
of our deployments.


Using ChaosKube is a manual step we do after our weekly demos. The intended
use case of ChaosKube is to kill pods randomly at random times during a
working day to test the ability to recover. The way we use it is a bit different,
we manually launch ChaosKube in debug mode and manually identify the weak
points of our deployment.

Later, we intend to integrate it into our CI pipeline, so whenever new changes
are rolled out we have a ChaosKube run for that release.


The deploy_chaoskube.sh
installs and unleashes ChaosKube by scheduling a run 10m after installing ChaosKube by default. It also sets up
the needed service account and role if RBAC is enabled.

After you clone the charts repository, to install and unleash ChaosKube, run:

scripts/deploy_chaoskube.sh up


ChaosKube can be configured by editing the scripts/chaoskube-resources/values.yaml
file. For more info read the official ChaosKube docs.

You can also configure the deployment with flags on the script. To find all available options, run:

scripts/deploy_chaoskube.sh -h

Visit the README’s values section for a full list of options to pass via --set arguments.

Read article

Still Thinking?
Give us a try!

We embrace agility in everything we do.
Our onboarding process is both simple and meaningful.
We can't wait to welcome you on AiDOOS!