| commit | 5c52ec102b56c1db3f2718832a6e77aeaa795c6b | [log] [tgz] |
|---|---|---|
| author | Ariel T. Glenn <ariel@wikimedia.org> | Mon Nov 02 14:02:10 2026 -0800 |
| committer | jenkins-bot <jenkins-bot@gerrit.wikimedia.org> | Wed Nov 04 17:41:02 2026 +0000 |
| tree | a65f1c0b53e6542177fbb9333186c9e4857862d0 | |
| parent | 36e689787fdce047cdb0a04a9ec6b7d0beb2ab87 [diff] |
changeprop: node 20 to node 26 See Iceb6de612640d483a18a35119b03f5893d02f82b Bug: T442195 Change-Id: I7759541f20df86b38726f77d582f1fc07cb35daa
This is the repo that powers https://helm-charts.wikimedia.org/stable/.
Here you will find the various helm charts the Wikimedia Foundation uses in developing software and deploying it to production.
If you want to create a new chart:
pip3 install sextantrake, the ruby task executor./create_new_service.shcharts/<your-chart-name>rake run_locally["check_charts[lint/validate\,<your-chart-name>]"]. WARNING: on M1 macs this could be unbearably slow at the moment.If two separate charts have templates with the same names and are deployed in the same release, the last definition of the template will be used for both charts. Please take this into account when designing new charts.
The values.yaml files provided by any chart are defaults and their purpose is to help deployment under development clusters. Actual values used in production are not kept here.
The _scaffold/ directory is used by the create_new_service.sh script, it's best to leave it alone.
The python/ directory holds utility code for use with charts. It can be included in PYTHONPATH to make these utilities available.
The makefile/ directory contains reusable makefile snippets.
Further documenation can be found on Wikitech
If you want to update an existing chart then changes should be made to it in the charts/ directory.
The changes should include incrementing the chart's version in the respective Chart.yaml file.
To avoid changes without version bump, a pre-commit hook is available at the repository root. You can symlink it to .git/hooks/.
The resulting files and changes should then be uploaded to Gerrit for code review.
Every chart created by our scaffolding will have:
package.json file, where the modules we're using in that chart are indicated. In this file only major.minor versions should be specifiedpackage.lock file where the aforementioned dependencies are frozen to a specific versiontemplates/vendor directory where the modules at the correct version are copied. To manage these dependencies, we use a tool called sextant. Please see its README for details on its usage.Charts are linted using helm lint and helm template; the resulting templates are also checked to ensure they produce valid YAML files.
Many charts use feature flags like monitoring.enabled: true to include or omit artifacts from the generated configuration. These optional features can and should be tested by providing values overrides for each feature flag. The tests will run the lint and template steps once with just your values.yaml data and then again for each YAML file in the chart's .fixtures/ directory.
In addition to the basic linting and template validation, all service deployments under helmfile.d/services are checked by each test run. Settings expected to be loaded from puppet managed files under /etc/helmfile-defaults during a deployment are not present in the testing environment. You can provide necessary values for testing by creating a helmfile.d/services/$SERVICE/.fixtures.yaml file to simulate production data.
Charts may provide a Makefile (or Rakefile) that defines targets for unit testing. This feature is still experimental. If a Makefile (or Rakefile) exists, it must define a ci_test (rake) resp. ci-test (make) target is defined. This target will be invoked in CI via the top-level Rakefile.
Similarly, charts and service definitions may provide a Makefile (or Rakefile) that defines targets for integration testing on the staging cluster and local minikube environments. By convention, the check target would be used for this purpose.
While the helm charts specification allows for a per chart license to be specified, we are following a more strict approach. All of the charts in this repo MUST have the exact same GPL-3.0-or-later license. See our LICENSE file for full license information.
