opendesk-edu

Developing openDesk deployment automation

Contributions to this fork are welcome! See CONTRIBUTING.md for guidelines.

Note: The workflow documentation below describes the upstream openDesk development process on GitLab, which uses a develop branch and Gitflow. This GitHub fork uses a simplified main-branch workflow. When contributing here, branch off from main and submit PRs against main.

Overview

The following sketch provides a high-level overview to get a basic understanding of the deployment-relevant structure of this repository. Understanding that structure is vital if you want to contribute to developing the openDesk platform.

flowchart TD
 J[helmfile.yaml.gotmpl\nor a helmfile outside of this repository]-->A
 J-->K[./helmfile/environemnts/*your_environment*/values.yaml.gotmpl\nor another environment values file]
 A[./helmfile_generic.yaml.gotmpl]-->B[./helmfile/apps/*all_configured_apps*/helmfile.yaml.gotmpl\nReferences the relevant app Helm\ncharts using details from 'charts.yaml.gotmpl']
 B-->C[./values-*all_configured_components*.yaml.gotmpl\nValues to template the charts\nwith references to the `images.yaml.gotmpl`]
 A-->D[./helmfile/environments/default/*\nwith just some examples below]
 D-->F[charts.yaml.gotmpl]
 D-->G[images.yaml.gotmpl]
 D-->H[global.*]
 D-->I[secrets.yaml.gotmpl\nreplicas.yaml.gotmpl\nresources.yaml.gotmpl\n...]
 A-->|overwrite defaults with your\ndeployment/environment specific values|E[./helmfile/environments/default/values.yaml.gotmpl]

The helmfile.yaml.gotmpl file in the root folder is the foundation for the entire deployment. It references the helmfile_generic.yaml.gotmpl file, which includes app-specific helmfile.yaml.gotmpl files and global values files located in ./environments/default.

helmfile.yaml.gotmpl also refers to three predefined environments: dev, test, and prod.

The helmfile_generic.yaml.gotmpl file is designed to be referenced from external repositories, where custom environments may be defined. An example is demonstrated in the helmfile.yaml.gotmpl file.

Before you investigate any app-specific configuration, it is recommended that you review the contents of ./helmfile/environments/default to understand what configuration details are set there, as the app deployments reference them.

Default branch and branching

This fork uses main as the only long-lived branch. Branch off from main for all contributions.

The upstream openDesk project on GitLab uses a Gitflow model with a develop branch. The section below is kept for reference when working with upstream code.

External artifacts - charts.yaml.gotmpl and images.yaml.gotmpl

The charts.yaml.gotmpl and images.yaml.gotmpl files are the central place to reference any external artifacts used for the deployment.

Besides the deployment automation itself, some tools work with the contents of the files:

Please find details on these tools below.

Linting

In the project’s CI, there is a step dedicated to lint the two yaml files, as we want them to be in

In the linting step, the openDesk CI CLI is used to apply the aforementioned sorting, and the result is compared with the unsorted version. If there is a delta, the linting fails, and you can fix it by running the CLI tool locally, verifying and applying the result to your branch.

[!note] Please ensure that in component blocks, you use comments only at the beginning of the block or at its end. Ideally, you stick with the many available examples in the yaml files.

Example:

 synapse:
 # providerCategory: "Supplier"
 # providerResponsible: "Element"
 # upstreamRegistry: "https://registry-1.docker.io"
 # upstreamRepository: "matrixdotorg/synapse"
 # upstreamMirrorTagFilterRegEx: '^v(\d+)\.(\d+)\.(\d+)$'
 # upstreamMirrorStartFrom: ["1", "91", "2"]
 registry: "registry.opencode.de"
 repository: "BMI/opendesk/components/supplier/element/images-mirror/synapse"
 tag: "v1.91.2@sha256:1d19508db417bb2b911c8e086bd3dc3b719ee75c6f6194d58af59b4c32b11322"

Disable linting selectively

If you follow the “push early, push often” paradigm to save your work to the central Git instance, or you just fix a typo in existing documentation, you can avoid the CI and its linting being executed, as it might not offer additional value.

GitLab offers two options to skip the CI on a commit/push:

  1. Add [ci skip] to your commit message (details). Note: The string has to be removed before merging your feature branch into develop.
  2. Use the related git push option git push -o ci.skip (details).

Renovate

Uses a regular expression to match the values of the following attributes:

Checks for newer versions of the given artifact and creates an MR containing the newest version’s tag (and digest).

Mirroring

[!note] The mirror is scheduled to run every hour at 42 minutes past the hour.

openDesk strives to make all relevant artifacts available on openCode so there is a mirroring process configured to pull artifacts that do not originate from openCode into projects called *-Mirror within the openDesk Components repository.

The mirror script takes the information on what artifacts to mirror from the annotation inside the two yaml files:

Get new artifacts mirrored

If you want new images or charts mirrored that are not yet included in one of the yaml files, you can add them in your branch, including the aforementioned mirror annotations, and ask somebody from the platform development team to trigger the mirror’s CI based on your branch.

Once your branch is merged into develop, your artifacts are mirrored hourly.

Creating new charts/images

When you create new Helm charts, please check out the openDesk Best Practices for Helm charts.

You may also want to make use of our standard CI to quickly get Helm charts and container images that are signed, linted, scanned, and released. Check out the .gitlab-ci.yaml files in the project’s Charts or Images to get an idea just how little you need to do by yourself.

This site is open source. Improve this page.